HY TX 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
---
I wonder how much placebo "PHY TX error was fi
On Monday 16 March 2009 18:20:18 David Ellingsworth wrote:
> Thank you all for the helpful information... Once the weekend comes
> around again, I'll take a look a trying to get something working.
I just took a good'ol WRT54Gv2.2 (rev7 wireless core) and put latest OpenWRT
trunk on it. It works pr
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
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
> > http://www.linuxwireless.org/en/
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 occasion
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
https://lists
This fixes compilation, if the PCI core is disabled.
Signed-off-by: Michael Buesch
---
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
.
Signed-off-by: Michael Buesch
---
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/wireless/b43/x
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
> > figure
On Wednesday 25 February 2009 18:33:38 Francesco Gringoli wrote:
> but I don't know if there is anyone who cares about :-)
Well, indeed. ;)
You should throw your broken hw away, if it causes harmful interference.
It's as simple as that. Problem solved. :)
Hardware simply often _is_ crap and caus
"warning: large integer implicitly truncated to unsigned type"
Signed-off-by: Michael Buesch
---
Virtual fists were already shaked, so I need to hurry up to fixup my crap. :P
Index: wireless-testing/drivers/net/wireless/b
On Monday 23 February 2009 18:36:12 Larry Finger wrote:
> More food for thought:
>
> My BCM4306/2 in a Cardbus format has a maxpbg value that translates to 10 dBm.
> It routinely transmits at 5-6 Mb/s in my normal setting. When I reprogrammed
> the
> SPROM to 20 dBm, it would start out at the abo
On Monday 23 February 2009 13:52:04 mtcs...@yahoo.com wrote:
> Good morning Michael. So, to be sure I've got it right; I want the second
> patch and not the first. I need to apply it to this morning's compat sources,
> not two days ago?
right.
--
Greetings, Michael.
___
On Monday 23 February 2009 13:25:36 Michael Buesch wrote:
> 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
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 Frequenc
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 usin
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 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 deb
On Friday 20 February 2009 21:10:13 Larry Finger wrote:
> 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
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.
>
> Howe
This patch converts code to use the new b43_radio_mask() API.
The semantic patch that makes this change is as follows:
//
@@
expression dev, addr, mask;
@@
-b43_radio_write16(dev, addr, b43_radio_read16(dev, addr) & mask);
+b43_radio_mask(dev, addr, mask);
//
Signed-off-by: Michael Bu
gned-off-by: Michael Buesch
---
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/wireless/b43/
This patch converts code to use the new b43_radio_set() API.
The semantic patch that makes this change is as follows:
//
@@
expression dev, addr, set;
@@
-b43_radio_write16(dev, addr, b43_radio_read16(dev, addr) | set);
+b43_radio_set(dev, addr, set);
//
Signed-off-by: Michael Buesch
f-by: Michael Buesch
---
Index: wireless-testing/drivers/net/wireless/b43/phy_a.c
===
--- wireless-testing.orig/drivers/net/wireless/b43/phy_a.c 2009-02-20
19:05:38.0 +0100
+++ wireless-testing/drivers/net/wireless/b43/phy
This patch converts code to use the new b43_phy_set() API.
The semantic patch that makes this change is as follows:
//
@@
expression dev, addr, set;
@@
-b43_phy_write(dev, addr, b43_phy_read(dev, addr) | set);
+b43_phy_set(dev, addr, set);
//
Signed-off-by: Michael Buesch
---
Index
This patch converts code to use the new b43_phy_mask() API.
The semantic patch that makes this change is as follows:
//
@@
expression dev, addr, mask;
@@
-b43_phy_write(dev, addr, b43_phy_read(dev, addr) & mask);
+b43_phy_mask(dev, addr, mask);
//
Signed-off-by: Michael Buesch
---
I
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, this is an excellent task for coccinelle/spatch.
So here's a series of patches,
This implements the new sw scan callbacks in b43.
They are currently used to turn CFP update in the microcode off while scanning.
Signed-off-by: Michael Buesch
---
John, please put on top of the mac80211 sw scan notifier patch.
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
---
John, this doesn't fix know bugs. Please queue for the next feature release.
Index: wireless-testing/drivers/net/wirele
Do not turn off the crystal, if the boardflags tell us so.
Signed-off-by: Michael Buesch
---
John, this doesn't fix known bugs. Please queue for the next feature release.
Index: wireless-testing/drivers/net/wireless/b43/m
This fixes initialization of some radio related hostflags.
Signed-off-by: Michael Buesch
---
John, this doesn't fix a known bug. Please queue for the next feature release.
Index: wireless-testing/drivers/net/wireless/b43/m
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
---
Coded with a brown paper bad on the head
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.
>
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
---
Please queue on top of the DMA optimizations
tiny meta structures), but have twice
the number of TX slots available.
Signed-off-by: Michael Buesch
---
Please queue for the next round of features.
Index: wireless-testing/drivers/net/wireless/b43/dma.c
===
--- wireless-testing.or
ffset for the buffer size.
Signed-off-by: Michael Buesch
---
John, no need to push this as bugfix. Just push it with the next round of
features. This bug has always been there and it's hidden. So it doesn't
trigger for anybody.
Index: wireless-testing/drivers/net/wir
Move the DMA stop sanity check up a few lines, so it's actually
theoretically possible to trigger. (But it still shouldn't trigger, of course).
Signed-off-by: Michael Buesch
---
Index: wireless-testing/drivers/net/wireless
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
ouncement on
> > > bcm43xx-dev!? :) Congratulations for that whole work! :)
> >
> > I 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
On Wednesday 18 February 2009 03:33:01 Francesco Gringoli wrote:
> On Feb 18, 2009, at 12:23 AM, Michael Buesch wrote:
>
> > 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
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 chan
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 f
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
Bcm43xx-dev@list
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'r
From: Roel Kluin
This patch expands the parenthesis in the txctl reg write
of the LO calibration to enforce precedence rules.
Signed-off-by: Roel Kluin
Signed-off-by: Michael Buesch
---
John, please apply this bugfix.
diff --git a/drivers/net/wireless/b43/lo.c b/drivers/net/wireless/b43
On Saturday 14 February 2009 16:22:47 Michael Buesch wrote:
> On Saturday 14 February 2009 11:02:31 [ tR3nt R32n0r ] wrote:
> > Hello,
> >
> > The capture starting from 802.11 header (radiotap header omitted) with
> > Atheros AR5001X+ Wireless Network Adapter (rev 01
On Saturday 14 February 2009 11:02:31 [ tR3nt R32n0r ] wrote:
> Hello,
>
> The capture starting from 802.11 header (radiotap header omitted) with
> Atheros AR5001X+ Wireless Network Adapter (rev 01) and D-Link System DWA-140
> 802.11n Adapter [ralink rt2870] (except sequence number):
>
> 7
This adds the initial parts of the LP-PHY TX power control.
This also adds helper functions for bulk access of LP tables.
Signed-off-by: Michael Buesch
---
Index: wireless-testing/drivers/net/wireless/b43/b43.h
===
--- wireless
On Wednesday 04 February 2009 10:22:53 Lorenzo Nava wrote:
>
> On Feb 4, 2009, at 4:12 AM, Larry Finger wrote:
>
> > Francesco,
> >
> > I have coded b43 to dump the microcode PSM when
> > b43_dma_handle_txstatus is called for an skb that has already been
> > processed and deleted. This dump is fo
On Wednesday 04 February 2009 04:12:46 Larry Finger wrote:
> Francesco,
>
> I have coded b43 to dump the microcode PSM when
> b43_dma_handle_txstatus is called for an skb that has already been
> processed and deleted. This dump is for V5.0 of the open firmware and
> includes everything but the PC
This fixes the crystal frequency calculations in the b2062 init code.
Signed-off-by: Michael Buesch
---
This patch depends on the SSB PMU code.
Index: wireless-testing/drivers/net/wireless/b43/phy_lp.c
===
--- wireless
A few bugs were fixed in the LP baseband init specs.
Signed-off-by: Michael Buesch
---
Please queue on top of the other LP-PHY patches.
Index: wireless-testing/drivers/net/wireless/b43/phy_lp.c
===
--- wireless-testing.orig
This adds support for the SSB PMU.
A PMU is found on Low-Power devices.
Signed-off-by: Michael Buesch
---
John, please queue for the next round of features.
Index: wireless-testing/drivers/ssb/Makefile
===
--- wireless
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 0x
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
> > do
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
>
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
>
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
> >
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
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 thi
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
> &g
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
This adds initialization code for the 2062 radio.
Signed-off-by: Michael Buesch
---
Index: wireless-testing/drivers/net/wireless/b43/phy_lp.c
===
--- wireless-testing.orig/drivers/net/wireless/b43/phy_lp.c 2009-01-31
17:19
This adds code for the baseband init of LP-PHY >=2.
Signed-off-by: Michael Buesch
---
Index: wireless-testing/drivers/net/wireless/b43/Makefile
===
--- wireless-testing.orig/drivers/net/wireless/b43/Makefile 2009-01-31
16
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
---
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 are for this kind of c
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'r
On Saturday 31 January 2009 07:54:20 Larry Finger wrote:
> I changed the dma.c code to WARN_ON rather than BUG_ON
Can you send this patch upstream?
> b43 TX status reports:
>
> index | cookie | seq | phy_stat | frame_count | rts_count |
> supp_reason | pm_indicated | intermediate | for_ampdu | a
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 handling hasn't changed in years.
> >
>
> Yes, but I didn't mean that the code has some bug. Let's say, for
> example, that
On Friday 30 January 2009 09:06:34 Lorenzo Nava wrote:
> I was wonder if the problem can be in any way related to DMA slots. Is
> it possible that, with the heavy load test, you filled all DMA rx ring
> slots?
I think that's rather unlikely, however. The DMA code is basically unchanged
for months
On Thursday 29 January 2009 18:48:15 Larry Finger wrote:
> Francesco,
>
> Opensource firmware 5.1 works with my BCM4318; however, under heavy
> load with a ping running in one window and 10 second bursts of tcpperf
> transmissions in another, the kernel (2.6.29-rc2-wl) panicked by
> hitting the BU
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.
__
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
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 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
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 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 i
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
---
John, please queue for the next feature push.
Index: wireless-testing/driver
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 monitor mode without associating first.
>
> I had alre
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
---
Index: wireless-testing/drivers/net/wireless/b43/phy_g.c
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.
> &
only matter on
multiband
devices, which are not implemented yet anyway.
Signed-off-by: Michael Buesch
---
John, please queue for the next feature round.
Index: wireless-testing/drivers/net/wireless/b43/main.c
===
--- wireless-testi
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 t
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 a
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 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 b
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:
http://bu3sch.de/patches/wire
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
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
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
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 propriet
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?
&g
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 fo
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 th
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 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 intr
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
>
On Wednesday 14 January 2009 02:19:05 David Ellingsworth wrote:
> On Tue, Jan 13, 2009 at 6:09 PM, Paul Harris 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 UNIX system
On Wednesday 14 January 2009 08:15:37 YanBo wrote:
[snip]
You can add
Acked-by: Michael Buesch
to all of these patches, after fixing the issues Johannes reported.
Please send them directly to John afterwards and CC me.
--
Greetings, Michael
401 - 500 of 2290 matches
Mail list logo
