On Sunday 25 March 2007 15:45, Larry Finger wrote:
From: David Woodhouse [EMAIL PROTECTED]
Recent changes in the specs that were introduced in commit
740ac4fb08866d702be90f167665d03759bd27d0 were incorrect and resulted in
machine check
errors on the PPC architecture for G PHY's with a
On Thu, Mar 22, 2007 at 05:02:45PM -0400, Pavel Roskin wrote:
On Thu, 2007-03-22 at 15:36 -0500, Larry Finger wrote:
I think softmac and bcm43xx-sm should be in one tarball and should be
built
together with one make invocation. Just melt the codebases together. :)
That's another
On Thu, Mar 22, 2007 at 02:35:14PM -0500, Larry Finger wrote:
Developing a V3 firmware driver for 802.11b devices doesn't seem to be
viable. From what I see in
the latest versions of the specifications, support for 802.11b devices is
disappearing from the
Broadcom drivers. Thus, I think a
On Fri, 23 Mar 2007 17:20:33 +0100
Michael Buesch [EMAIL PROTECTED] wrote:
void bcm43xx_radio_set_tx_iq(struct bcm43xx_private *bcm)
{
static const u8 data_high[5] = { 0x00, 0x40, 0x80, 0x90, 0xD0 };
static const u8 data_low[5] = { 0x00, 0x01, 0x05, 0x06, 0x0A };
u16 tmp =
Fix a duplicated leftshift in bcm43xx_radio_set_tx_iq. data_high values are
already leftshifted. Thanks to Michael Buesch for spotting this.
Signed-off-by: Stefano Brivio [EMAIL PROTECTED]
---
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_radio.c
On Fri, 23 Mar 2007 12:37:51 -0500
Larry Finger [EMAIL PROTECTED] wrote:
I think we have a plan for the future of bcm43xx-softmac once the
bcm43xx-mac80211 version goes into mainline. Unfortunately it cannot just
be abandoned as there will be no support for 802.11b-only devices in
On Friday 23 March 2007 22:24, Will Dyson wrote:
When the chip is limited to 30bit DMA, allocate RX buffers in ZONE_DMA. When
the network stack passes us TX buffers that cannot be mapped because of the
limitation (with an address 1GB), allocate a bounce buffer in ZONE_DMA and
copy the packet
On Thursday 22 March 2007 20:35, Larry Finger wrote:
Michael Buesch wrote:
On Thursday 22 March 2007 13:58, John W. Linville wrote:
Why? What value do you predict in having an out-of-tree softmac
version available? Would that effort be better spent on improving
the in-tree mac80211
On Thursday 22 March 2007 21:55, Larry Finger wrote:
Michael Buesch wrote:
Ah, and yeah. There is the issue of symbol clashes with bcm43xx-mac80211.
Is that an issue when built modular? We should make life of distributors
easy by allowing both bcm43xx-sm and bcm43xx-mac80211 be loaded at
On Thursday 22 March 2007 22:09, Larry Finger wrote:
Based on Michael's comments, I think it would be easier to teach
bcm43xx-softmac to work with
mac80211 than it would be to put V3 firmware back in bcm43xx-mac80211. Do you
agree Michael?
Putting v3 support into bcm43xx-mac80211 is not an
On Thursday 22 March 2007 22:02, Pavel Roskin wrote:
It will be easy enough to change bcm43xx-sm names to avoid
them.
s/bcm43xx/bcm4301/
or something like that
I'd vote for that name change, yes.
--
Greetings Michael.
___
Bcm43xx-dev mailing
On Friday 23 March 2007 18:37, Larry Finger wrote:
I think we have a plan for the future of bcm43xx-softmac once the
bcm43xx-mac80211 version goes into
mainline. Unfortunately it cannot just be abandoned as there will be no
support for 802.11b-only
devices in bcm43xx-mac80211.
The steps
On Friday 23 March 2007 20:23, Stefano Brivio wrote:
Fix a duplicated leftshift in bcm43xx_radio_set_tx_iq. data_high values are
already leftshifted. Thanks to Michael Buesch for spotting this.
Signed-off-by: Stefano Brivio [EMAIL PROTECTED]
I think you should probably write your APHY stuff
Is anyone willing to trade a working BCM4301 802.11b PCMCIA card for a working
BCM4306 802.11b/g
card? I need one for debugging future versions of the bcm43xx (soon to be
bcm4301) driver for the
days when mac80211 goes into mainline.
It would be easier if the donor is in the US, but not
Check result of dma_map_single(), print warnings and propagate errors up the
call stack.
Signed-off-by: Will Dyson [EMAIL PROTECTED]
---
.../net/wireless/mac80211/bcm43xx/bcm43xx_dma.c| 39
+++-
1 files changed, 30 insertions(+), 9 deletions(-)
diff --git
From: David Woodhouse [EMAIL PROTECTED]
Recent changes in the specs that were introduced in commit
740ac4fb08866d702be90f167665d03759bd27d0 were incorrect and resulted in machine
check
errors on the PPC architecture for G PHY's with a revision number equal to 1.
The
two offending changes are
When the chip is limited to 30bit DMA, allocate RX buffers in ZONE_DMA. When
the network stack passes us TX buffers that cannot be mapped because of the
limitation (with an address 1GB), allocate a bounce buffer in ZONE_DMA and
copy the packet there.
Signed-off-by: Will Dyson [EMAIL PROTECTED]
On Sun, 25 Mar 2007 19:02:52 +0200
Stefano Brivio [EMAIL PROTECTED] wrote:
On Sun, 25 Mar 2007 09:38:49 -0500
Larry Finger [EMAIL PROTECTED] wrote:
Is anyone willing to trade a working BCM4301 802.11b PCMCIA card for a
working BCM4306 802.11b/g card? I need one for debugging future
Stefano Brivio wrote:
On Sun, 25 Mar 2007 09:38:49 -0500
Larry Finger [EMAIL PROTECTED] wrote:
Is anyone willing to trade a working BCM4301 802.11b PCMCIA card for a
working BCM4306 802.11b/g card? I need one for debugging future versions
of the bcm43xx (soon to be bcm4301) driver for the
Introduce and use a set of accessor functions to return the DMA capabilities
of
the chip. The detected DMA mask is accessible through bcm43xx_wldev and it
cannot vary between the rings on a chip, so no need to separately keep track
of
it on a per-ring basis. This paves the way for checking for
On Thu, 2007-03-22 at 08:58 -0400, John W. Linville wrote:
Although it's unfortunate that I cannot test dadwifi and bcm43xx on the
same kernel. It's quite bad, especially on the slow G3 PowerMac.
Why not? The wireless-dev kernel still has the softmac bcm43xx driver,
as well as the
On Thu, 2007-03-22 at 16:19 -0500, Larry Finger wrote:
Compiling both as modules, I didn't get any messages about duplicate symbols.
Did I miss something?
That's correct. I thought your concern was about conflicts if both
drivers are linked into the kernel.
But what's needed now is a
Michael Buesch wrote:
On Thursday 22 March 2007 22:02, Pavel Roskin wrote:
It will be easy enough to change bcm43xx-sm names to avoid
them.
s/bcm43xx/bcm4301/
or something like that
I'd vote for that name change, yes.
What about bcm43xx-bphy since the 4303 would also be supported by
I'm not sure whether this information is of interest for you, but here
it is: (bcm4310 is not in the the list on the website - is it actually a
4312?)
Yes, the PCI ID database has it incorrectly listed.
-Joe
___
Bcm43xx-dev mailing list
Michael Buesch wrote:
On Sunday 25 March 2007 15:45, Larry Finger wrote:
From: David Woodhouse [EMAIL PROTECTED]
Recent changes in the specs that were introduced in commit
740ac4fb08866d702be90f167665d03759bd27d0 were incorrect and resulted in
machine check
errors on the PPC architecture
25 matches
Mail list logo
