Re: [PATCH] bcm43xx: Fix machine check on PPC for version 1 PHY
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 revision number equal to 1.
The
two offending changes are reverted.
I'm not sure this patch is complete.
Joseph made changes to the specs that should fix the issue completely.
I didn't look at the changes, yet.
Signed-off-by: David Woodhouse [EMAIL PROTECTED]
Signed-off-by: Larry Finger [EMAIL PROTECTED]
---
John,
This fix should be applied to wireless-2.6 and set to 'upstream-fixes'. I
hope is makes
it into 2.6.21 before the final release. The debugging of this issue was
mostly done
by David with additional help by Pavil Roskin.
Larry
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_phy.c
===
--- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_phy.c
+++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_phy.c
@@ -762,7 +762,7 @@ static void bcm43xx_phy_initb5(struct bc
if (radio-version == 0x2050)
bcm43xx_phy_write(bcm, 0x0038, 0x0667);
- if (phy-type == BCM43xx_PHYTYPE_G) {
+ if (phy-connected) {
if (radio-version == 0x2050) {
bcm43xx_radio_write16(bcm, 0x007A,
bcm43xx_radio_read16(bcm, 0x007A)
@@ -1197,7 +1197,7 @@ static void bcm43xx_phy_initg(struct bcm
bcm43xx_phy_write(bcm, 0x0811, 0x0400);
bcm43xx_phy_write(bcm, 0x0015, 0x00C0);
}
- if (phy-connected) {
+ if (phy-rev = 2 phy-connected) {
tmp = bcm43xx_phy_read(bcm, 0x0400) 0xFF;
if (tmp 6) {
bcm43xx_phy_write(bcm, 0x04C2, 0x1816);
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: combined on 2.6.20.3
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 problem with symbols if softmac is enabled in the kernel. Unless softmac is changing quickly or has major bugs in the recent kernels, I suggest leaving it in the kernel. Both the old driver and softmac are likely to remain in the kernel for some period of time (however short that might be). When the drivers come out, softmac comes out too. It certainly will not be left in the kernel to support an out of kernel driver. John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: combined on 2.6.20.3
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 standalone bcm43xx-softmac solution would be best. I'm not sure I follow the reasoning here. Won't the softmac driver still need v3 firmware? Is converting the softmac driver to mac80211 (as bcm43xx-old or somesuch) really a bigger job than trying to maintain out-of-tree code for both the driver and the softmac component from now on? You are also imposing upon distros a choice between shipping out-of-kernel drivers or just not supporting certain hardware. Both choices suck -- I can elaborate if it isn't clear why. I'd much rather see two drivers, one for v3 firmware and one for later firmware. Why is this such a problem? Afterall, at one time the mac80211 (then d80211) driver supported v3 firmware. John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: APHY: bcm43xx_radio_set_tx_iq() seems wrong.
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 = bcm43xx_radio_read16(bcm, 0x001E);
int i, j;
for (i = 0; i 5; i++) {
for (j = 0; j 5; j++) {
if (tmp == (data_high[i] 4 | data_low[j])) {
This leftshift by 4 seems wrong, as the data_high values already look
like leftshifted.
Sorry, my fault, patches coming.
--
Ciao
Stefano
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] bcm43xx: fix radio_set_tx_iq
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
b/drivers/net/wireless/bcm43xx/bcm43xx_radio.c
index 32beb91..d153b58 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_radio.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_radio.c
@@ -1579,7 +1579,7 @@ void bcm43xx_radio_set_tx_iq(struct bcm4
for (i = 0; i 5; i++) {
for (j = 0; j 5; j++) {
- if (tmp == (data_high[i] 4 | data_low[j])) {
+ if (tmp == (data_high[i] | data_low[j])) {
bcm43xx_phy_write(bcm, 0x0069, (i - j) 8 |
0x00C0);
return;
}
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: RFC: Future plans for bcm43xx-softmac
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 bcm43xx-mac80211. The steps to be done are as follows: 1. Change the namespace from bcm43xx to bcm4301. This will both reflect the purpose of the changed driver as well as prevent namespace collisions with the bcm43xx-mac80211 version in case both are built into the kernel. I'm quite sure you know, bcm4301 isn't the only 802.11b-only device. There's bcm4303 too. Anyway, naming the driver bcm4301 sounds reasonable to me. Please comment on this plan. ACK. -- Ciao Stefano ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH 3/3] bcm43xx-mac80211: Work around 30bit DMA limitation
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 there.
I _still_ think that this should be fixed in the arch DMA code
and _not_ in every single driver on earth. But I discussed this in
the past.
Signed-off-by: Will Dyson [EMAIL PROTECTED]
---
.../net/wireless/mac80211/bcm43xx/bcm43xx_dma.c| 52
+---
1 files changed, 45 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/mac80211/bcm43xx/bcm43xx_dma.c
b/drivers/net/wireless/mac80211/bcm43xx/bcm43xx_dma.c
index d09b849..8f6d434 100644
--- a/drivers/net/wireless/mac80211/bcm43xx/bcm43xx_dma.c
+++ b/drivers/net/wireless/mac80211/bcm43xx/bcm43xx_dma.c
@@ -397,6 +397,9 @@ static int alloc_ringmemory(struct bcm43xx_dmaring
*ring)
Your patches are all damaged. Please fix your mailer.
{
struct device *dev = ring-dev-dev-dev;
+/* Dont need to test for 30bit dma here.
+ * dma_alloc_coherent respects the dma_mask
+ */
ring-descbase = dma_alloc_coherent(dev, BCM43xx_DMA_RINGMEMSIZE,
(ring-dmabase), GFP_KERNEL);
if (!ring-descbase) {
@@ -549,11 +552,15 @@ static int alloc_initial_descbuffers(struct
bcm43xx_dmaring *ring)
int i, err = -ENOMEM;
struct bcm43xx_dmadesc_generic *desc;
struct bcm43xx_dmadesc_meta *meta;
+gfp_t flags = GFP_KERNEL;
+
+if (bcm43xx_dma30(ring-dev))
+flags = GFP_DMA;
Ehm, no. This would always allocate in the DMA zone, even if there
is no requirement to do so (on i386 for example).
for (i = 0; i ring-nr_slots; i++) {
desc = ring-ops-idx2desc(ring, i, meta);
-err = setup_rx_descbuffer(ring, desc, meta, GFP_KERNEL);
+err = setup_rx_descbuffer(ring, desc, meta, flags);
if (err) {
printk(KERN_ERR PFX Failed to allocate initial
descbuffers\n);
goto err_unwind;
@@ -730,6 +737,7 @@ struct bcm43xx_dmaring * bcm43xx_setup_dmaring(struct
bcm43xx_wldev *dev,
struct bcm43xx_dmaring *ring;
int err;
int nr_slots;
+gfp_t dma_flags = GFP_KERNEL;
ring = kzalloc(sizeof(*ring), GFP_KERNEL);
if (!ring)
@@ -744,9 +752,12 @@ struct bcm43xx_dmaring * bcm43xx_setup_dmaring(struct
bcm43xx_wldev *dev,
if (!ring-meta)
goto err_kfree_ring;
if (for_tx) {
+if (bcm43xx_dma30(dev))
+dma_flags = GFP_DMA;
Same here.
+/* only this allocation is for DMA */
ring-txhdr_cache = kcalloc(nr_slots,
sizeof(struct bcm43xx_txhdr_fw4),
-GFP_KERNEL);
+dma_flags);
if (!ring-txhdr_cache)
goto err_kfree_meta;
}
@@ -1020,9 +1031,11 @@ static int dma_tx_fragment(struct bcm43xx_dmaring
*ring,
const struct bcm43xx_dma_ops *ops = ring-ops;
u8 *header;
int slot;
+int err;
struct bcm43xx_dmadesc_generic *desc;
struct bcm43xx_dmadesc_meta *meta;
struct bcm43xx_dmadesc_meta *meta_hdr;
+struct sk_buff *bounce_skb;
#define SLOTS_PER_PACKET 2
assert(skb_shinfo(skb)-nr_frags == 0);
@@ -1052,9 +1065,27 @@ static int dma_tx_fragment(struct bcm43xx_dmaring
*ring,
memcpy(meta-txstat.control, ctl, sizeof(*ctl));
meta-skb = skb;
meta-is_last_fragment = 1;
+
meta-dmaaddr = map_descbuffer(ring, skb-data, skb-len, 1);
-if(dma_mapping_error(meta-dmaaddr))
-goto out_unmap_hdr;
+
+/* create a bounce buffer in zone_dma on mapping failure. */
+if (dma_mapping_error(meta-dmaaddr)) {
+bounce_skb = __dev_alloc_skb(skb-len, GFP_ATOMIC|GFP_DMA);
^^
Whitespace.
+if(!bounce_skb) {
^
Whitespace.
+err = -ENOMEM;
+goto out_unmap_hdr;
+}
+
+memcpy(skb_put(bounce_skb, skb-len), skb-data, skb-len);
+dev_kfree_skb_any(skb);
+skb = bounce_skb;
+meta-skb = skb;
+meta-dmaaddr = map_descbuffer(ring, skb-data, skb-len, 1);
+if (dma_mapping_error(meta-dmaaddr)) {
+err = -EIO;
+goto out_free_bounce;
+}
+}
ops-fill_descriptor(ring, desc, meta-dmaaddr,
skb-len, 0, 1, 1);
@@ -1064,10 +1095,12 @@ static int dma_tx_fragment(struct bcm43xx_dmaring
*ring,
ops-poke_tx(ring, next_slot(ring, slot));
return 0;
+out_free_bounce:
+dev_kfree_skb_any(skb);
out_unmap_hdr:
unmap_descbuffer(ring, meta_hdr-dmaaddr,
sizeof(struct bcm43xx_txhdr_fw4), 1);
-return -EIO;
+return err;
}
int bcm43xx_dma_tx(struct bcm43xx_wldev *dev,
@@ -1088,7 +1121,7 @@ int
Re: combined on 2.6.20.3
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 version? Once mac80211 is merged we probaby need a (out of tree?) fork of the bcm43xx-softmac to support old 802.11b cards. The new driver can't support this anymore (issues with firmware. It's simply too hard to support both architectures in one driver). We could probably still leave a stripped down bcm43xx-softmac in the kernel, though that would require for softmac to stay there, too. I lean towards doing an out of tree tarball to get the legacy stuff out of the main kernel tree. Larry, some opinion? To me, continuing support of 802.11b cards is a given. Knowing that there are problems with SoftMAC that will never be fixed, I think it should be removed from the kernel. Leaving it there would encourage its use and give the wrong impression. I have no problems with my continuing to support an out-of-tree version. Of course, I hope that the number of API and ABI breakages would be minimal. To my knowledge, the current code base provides close to optimal performance with the 802.11b cards. Of course, there is only one in our data base and they are not that abundant. Pavel clearly favors an out-of-tree solution over a patch set to add bcm43xx-softmac back into a source tree. That is OK with me. 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 standalone bcm43xx-softmac solution would be best. Ok, nice. So what if you start to prepare such an out-of-tree tarball? Such a tarball would: - Contain softmac code. - bcm43xx-sm code. - Makefiles to build all these as modules against the installed kernel. - Probably some compatibility stuff to make it compile against older kernels. - Would have all A and G devices ripped out of the PCI device ID list (important!) Besides that I would _not_ remove all A and G code (phy code and stuff), as that introduces a too high risk of breaking things for so little gain (slightly smaller module). You can look at the old SVN repository on berlios to get a Makefile for out-of-tree build for the driver. 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. :) 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 the same time. Does that sound reasonable? Or should I do it? -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: combined on 2.6.20.3
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 the same time. I don't think there are any symbol clashes. Well, if you compile both into the kernel image there _are_ symbol clashes. I think with modules they don't show up at runtime, as any non-exported symbol is de-facto static. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: combined on 2.6.20.3
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 option. Porting bcm43xx-sm to mac80211 is an option. It's not too hard. Incidentally, I have just demonstrated that bcm43xx-softmac and bcm43xx-mac80211 can coexist in the same kernel as long as the PCI-id is unique. In this way, we have a migration route that lets us defer any changes until sometime after mac80211 goes mainline. All we have to do is remove the A and G PHY ids from softmac. The ids for B PHYs are already removed from bcm43xx-mac80211. Please change the name(space) of bcm43xx-sm to bcm4301. Makes it _much_ more clear which hardware is supported by this driver. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: combined on 2.6.20.3
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 list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: RFC: Future plans for bcm43xx-softmac
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 to be done are as follows: 1. Change the namespace from bcm43xx to bcm4301. This will both reflect the purpose of the changed driver as well as prevent namespace collisions with the bcm43xx-mac80211 version in case both are built into the kernel. 2. Modify bcm4301 to use mac80211 rather than softmac. Although this process has the potential for introducing bugs into what is currently the stable version, it does allow the abandonment of softmac with its deficiencies, many of which are essentially uncorrectable. 3. The PCI-ids recognized by bcm4301-mac80211 will be restricted to the 802.11b-only devices and the configuration information will be modified. Step 1 will be completed very soon and the appropriate patches will be submitted to Linville's wireless-dev tree. I will be working on step 2 in the coming months and will submit those patches to the list for comments and testing. When ready, they too will be submitted to Linville. Once bcm43xx-mac80211 goes into mainline, the step 3 patches will be submitted. Please comment on this plan. I ACK this as-is. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] bcm43xx-mac80211: fix radio_set_tx_iq
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 against the development
tree, as only that has proper support for multiple 802.11 cores (4309).
diff --git a/drivers/net/wireless/mac80211/bcm43xx/bcm43xx_phy.c
b/drivers/net/wireless/mac80211/bcm43xx/bcm43xx_phy.c
index 10a82b1..a2c52f6 100644
--- a/drivers/net/wireless/mac80211/bcm43xx/bcm43xx_phy.c
+++ b/drivers/net/wireless/mac80211/bcm43xx/bcm43xx_phy.c
@@ -3802,7 +3802,7 @@ void bcm43xx_radio_set_tx_iq(struct bcm4
for (i = 0; i 5; i++) {
for (j = 0; j 5; j++) {
- if (tmp == (data_high[i] 4 | data_low[j])) {
+ if (tmp == (data_high[i] | data_low[j])) {
bcm43xx_phy_write(dev, 0x0069, (i - j) 8 |
0x00C0);
return;
}
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
I need a BCM4301
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 necessary. Thanks, Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH 1/3] bcm43xx-mac80211: Catch dma mapping failures.
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 a/drivers/net/wireless/mac80211/bcm43xx/bcm43xx_dma.c
b/drivers/net/wireless/mac80211/bcm43xx/bcm43xx_dma.c
index d53679d..4abc6c8 100644
--- a/drivers/net/wireless/mac80211/bcm43xx/bcm43xx_dma.c
+++ b/drivers/net/wireless/mac80211/bcm43xx/bcm43xx_dma.c
@@ -525,9 +525,11 @@ static int setup_rx_descbuffer(struct bcm43xx_dmaring
*ring,
return -ENOMEM;
dmaaddr = map_descbuffer(ring, skb-data,
ring-rx_buffersize, 0);
+if (dma_mapping_error(dmaaddr))
+return -EIO;
+
meta-skb = skb;
meta-dmaaddr = dmaaddr;
-
ring-ops-fill_descriptor(ring, desc, dmaaddr,
ring-rx_buffersize, 0, 0, 0);
@@ -552,8 +554,10 @@ static int alloc_initial_descbuffers(struct
bcm43xx_dmaring *ring)
desc = ring-ops-idx2desc(ring, i, meta);
err = setup_rx_descbuffer(ring, desc, meta, GFP_KERNEL);
-if (err)
+if (err) {
+printk(KERN_ERR PFX Failed to allocate initial
descbuffers\n);
goto err_unwind;
+}
}
mb();
ring-used_slots = ring-nr_slots;
@@ -1017,7 +1021,7 @@ struct bcm43xx_dmaring * parse_cookie(struct
bcm43xx_wldev *dev,
return ring;
}
-static void dma_tx_fragment(struct bcm43xx_dmaring *ring,
+static int dma_tx_fragment(struct bcm43xx_dmaring *ring,
struct sk_buff *skb,
struct ieee80211_tx_control *ctl)
{
@@ -1026,23 +1030,26 @@ static void dma_tx_fragment(struct bcm43xx_dmaring
*ring,
int slot;
struct bcm43xx_dmadesc_generic *desc;
struct bcm43xx_dmadesc_meta *meta;
+struct bcm43xx_dmadesc_meta *meta_hdr;
#define SLOTS_PER_PACKET 2
assert(skb_shinfo(skb)-nr_frags == 0);
/* Get a slot for the header. */
slot = request_slot(ring);
-desc = ops-idx2desc(ring, slot, meta);
-memset(meta, 0, sizeof(*meta));
+desc = ops-idx2desc(ring, slot, meta_hdr);
+memset(meta_hdr, 0, sizeof(*meta_hdr));
header = (ring-txhdr_cache[slot * sizeof(struct bcm43xx_txhdr_fw4)]);
bcm43xx_generate_txhdr(ring-dev, header,
skb-data, skb-len, ctl,
generate_cookie(ring, slot));
-meta-dmaaddr = map_descbuffer(ring, (unsigned char *)header,
+meta_hdr-dmaaddr = map_descbuffer(ring, (unsigned char *)header,
sizeof(struct bcm43xx_txhdr_fw4), 1);
-ops-fill_descriptor(ring, desc, meta-dmaaddr,
+if (dma_mapping_error(meta_hdr-dmaaddr))
+return -EIO;
+ops-fill_descriptor(ring, desc, meta_hdr-dmaaddr,
sizeof(struct bcm43xx_txhdr_fw4), 1, 0, 0);
/* Get a slot for the payload. */
@@ -1052,8 +1059,10 @@ static void dma_tx_fragment(struct bcm43xx_dmaring
*ring,
memcpy(meta-txstat.control, ctl, sizeof(*ctl));
meta-skb = skb;
-meta-dmaaddr = map_descbuffer(ring, skb-data, skb-len, 1);
meta-is_last_fragment = 1;
+meta-dmaaddr = map_descbuffer(ring, skb-data, skb-len, 1);
+if(dma_mapping_error(meta-dmaaddr))
+goto out_unmap_hdr;
ops-fill_descriptor(ring, desc, meta-dmaaddr,
skb-len, 0, 1, 1);
@@ -1061,6 +1070,12 @@ static void dma_tx_fragment(struct bcm43xx_dmaring
*ring,
/* Now transfer the whole frame. */
wmb();
ops-poke_tx(ring, next_slot(ring, slot));
+return 0;
+
+out_unmap_hdr:
+unmap_descbuffer(ring, meta_hdr-dmaaddr,
+sizeof(struct bcm43xx_txhdr_fw4), 1);
+return -EIO;
}
int bcm43xx_dma_tx(struct bcm43xx_wldev *dev,
@@ -1068,6 +1083,7 @@ int bcm43xx_dma_tx(struct bcm43xx_wldev *dev,
struct ieee80211_tx_control *ctl)
{
struct bcm43xx_dmaring *ring = dev-dma.tx_ring1;
+int err = 0;
assert(ring-tx);
if (unlikely(free_slots(ring) SLOTS_PER_PACKET)) {
@@ -1078,7 +1094,12 @@ int bcm43xx_dma_tx(struct bcm43xx_wldev *dev,
return NETDEV_TX_BUSY;
}
-dma_tx_fragment(ring, skb, ctl);
+err = dma_tx_fragment(ring, skb, ctl);
+if (unlikely(err)) {
+printkl(KERN_ERR PFX DMA tx mapping failure\n);
+return NETDEV_TX_BUSY;
+}
+
ring-nr_tx_packets++;
if (free_slots(ring) SLOTS_PER_PACKET) {
/* FIXME: we currently only have one queue */
--
1.5.0.3
--
Will Dyson
http://www.lucidts.com/
Linux/Mac/Win consulting
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] bcm43xx: Fix machine check on PPC for version 1 PHY
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 reverted.
Signed-off-by: David Woodhouse [EMAIL PROTECTED]
Signed-off-by: Larry Finger [EMAIL PROTECTED]
---
John,
This fix should be applied to wireless-2.6 and set to 'upstream-fixes'. I hope
is makes
it into 2.6.21 before the final release. The debugging of this issue was mostly
done
by David with additional help by Pavil Roskin.
Larry
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_phy.c
===
--- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_phy.c
+++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_phy.c
@@ -762,7 +762,7 @@ static void bcm43xx_phy_initb5(struct bc
if (radio-version == 0x2050)
bcm43xx_phy_write(bcm, 0x0038, 0x0667);
- if (phy-type == BCM43xx_PHYTYPE_G) {
+ if (phy-connected) {
if (radio-version == 0x2050) {
bcm43xx_radio_write16(bcm, 0x007A,
bcm43xx_radio_read16(bcm, 0x007A)
@@ -1197,7 +1197,7 @@ static void bcm43xx_phy_initg(struct bcm
bcm43xx_phy_write(bcm, 0x0811, 0x0400);
bcm43xx_phy_write(bcm, 0x0015, 0x00C0);
}
- if (phy-connected) {
+ if (phy-rev = 2 phy-connected) {
tmp = bcm43xx_phy_read(bcm, 0x0400) 0xFF;
if (tmp 6) {
bcm43xx_phy_write(bcm, 0x04C2, 0x1816);
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH 3/3] bcm43xx-mac80211: Work around 30bit DMA limitation
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]
---
.../net/wireless/mac80211/bcm43xx/bcm43xx_dma.c| 52
+---
1 files changed, 45 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/mac80211/bcm43xx/bcm43xx_dma.c
b/drivers/net/wireless/mac80211/bcm43xx/bcm43xx_dma.c
index d09b849..8f6d434 100644
--- a/drivers/net/wireless/mac80211/bcm43xx/bcm43xx_dma.c
+++ b/drivers/net/wireless/mac80211/bcm43xx/bcm43xx_dma.c
@@ -397,6 +397,9 @@ static int alloc_ringmemory(struct bcm43xx_dmaring
*ring)
{
struct device *dev = ring-dev-dev-dev;
+/* Dont need to test for 30bit dma here.
+ * dma_alloc_coherent respects the dma_mask
+ */
ring-descbase = dma_alloc_coherent(dev, BCM43xx_DMA_RINGMEMSIZE,
(ring-dmabase), GFP_KERNEL);
if (!ring-descbase) {
@@ -549,11 +552,15 @@ static int alloc_initial_descbuffers(struct
bcm43xx_dmaring *ring)
int i, err = -ENOMEM;
struct bcm43xx_dmadesc_generic *desc;
struct bcm43xx_dmadesc_meta *meta;
+gfp_t flags = GFP_KERNEL;
+
+if (bcm43xx_dma30(ring-dev))
+flags = GFP_DMA;
for (i = 0; i ring-nr_slots; i++) {
desc = ring-ops-idx2desc(ring, i, meta);
-err = setup_rx_descbuffer(ring, desc, meta, GFP_KERNEL);
+err = setup_rx_descbuffer(ring, desc, meta, flags);
if (err) {
printk(KERN_ERR PFX Failed to allocate initial
descbuffers\n);
goto err_unwind;
@@ -730,6 +737,7 @@ struct bcm43xx_dmaring * bcm43xx_setup_dmaring(struct
bcm43xx_wldev *dev,
struct bcm43xx_dmaring *ring;
int err;
int nr_slots;
+gfp_t dma_flags = GFP_KERNEL;
ring = kzalloc(sizeof(*ring), GFP_KERNEL);
if (!ring)
@@ -744,9 +752,12 @@ struct bcm43xx_dmaring * bcm43xx_setup_dmaring(struct
bcm43xx_wldev *dev,
if (!ring-meta)
goto err_kfree_ring;
if (for_tx) {
+if (bcm43xx_dma30(dev))
+dma_flags = GFP_DMA;
+/* only this allocation is for DMA */
ring-txhdr_cache = kcalloc(nr_slots,
sizeof(struct bcm43xx_txhdr_fw4),
-GFP_KERNEL);
+dma_flags);
if (!ring-txhdr_cache)
goto err_kfree_meta;
}
@@ -1020,9 +1031,11 @@ static int dma_tx_fragment(struct bcm43xx_dmaring
*ring,
const struct bcm43xx_dma_ops *ops = ring-ops;
u8 *header;
int slot;
+int err;
struct bcm43xx_dmadesc_generic *desc;
struct bcm43xx_dmadesc_meta *meta;
struct bcm43xx_dmadesc_meta *meta_hdr;
+struct sk_buff *bounce_skb;
#define SLOTS_PER_PACKET 2
assert(skb_shinfo(skb)-nr_frags == 0);
@@ -1052,9 +1065,27 @@ static int dma_tx_fragment(struct bcm43xx_dmaring
*ring,
memcpy(meta-txstat.control, ctl, sizeof(*ctl));
meta-skb = skb;
meta-is_last_fragment = 1;
+
meta-dmaaddr = map_descbuffer(ring, skb-data, skb-len, 1);
-if(dma_mapping_error(meta-dmaaddr))
-goto out_unmap_hdr;
+
+/* create a bounce buffer in zone_dma on mapping failure. */
+if (dma_mapping_error(meta-dmaaddr)) {
+bounce_skb = __dev_alloc_skb(skb-len, GFP_ATOMIC|GFP_DMA);
+if(!bounce_skb) {
+err = -ENOMEM;
+goto out_unmap_hdr;
+}
+
+memcpy(skb_put(bounce_skb, skb-len), skb-data, skb-len);
+dev_kfree_skb_any(skb);
+skb = bounce_skb;
+meta-skb = skb;
+meta-dmaaddr = map_descbuffer(ring, skb-data, skb-len, 1);
+if (dma_mapping_error(meta-dmaaddr)) {
+err = -EIO;
+goto out_free_bounce;
+}
+}
ops-fill_descriptor(ring, desc, meta-dmaaddr,
skb-len, 0, 1, 1);
@@ -1064,10 +1095,12 @@ static int dma_tx_fragment(struct bcm43xx_dmaring
*ring,
ops-poke_tx(ring, next_slot(ring, slot));
return 0;
+out_free_bounce:
+dev_kfree_skb_any(skb);
out_unmap_hdr:
unmap_descbuffer(ring, meta_hdr-dmaaddr,
sizeof(struct bcm43xx_txhdr_fw4), 1);
-return -EIO;
+return err;
}
int bcm43xx_dma_tx(struct bcm43xx_wldev *dev,
@@ -1088,7 +1121,7 @@ int bcm43xx_dma_tx(struct bcm43xx_wldev *dev,
err = dma_tx_fragment(ring, skb, ctl);
if (unlikely(err)) {
-printkl(KERN_ERR PFX DMA tx mapping failure\n);
+printkl(KERN_ERR PFX DMA tx failure\n);
return NETDEV_TX_BUSY;
}
@@ -1186,6 +1219,7 @@ static void dma_rx(struct bcm43xx_dmaring *ring,
u16 len;
int err;
dma_addr_t dmaaddr;
+gfp_t dma_flags;
desc = ops-idx2desc(ring, *slot, meta);
@@ -1253,8 +1287,12 @@ static void dma_rx(struct bcm43xx_dmaring *ring,
goto drop;
}
+dma_flags = GFP_ATOMIC;
+if (bcm43xx_dma30(ring-dev))
+dma_flags |= GFP_DMA;
+
dmaaddr = meta-dmaaddr;
-
Re: I need a BCM4301
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 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 necessary. If the trade doesn't succeed, feel free to buy a Linksys WMP11 on eBay, you will get a money refund. Ah, no, sorry, I didn't see you needed a PCMCIA card. Well, however, if you find something on eBay, just buy it. -- Ciao Stefano ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: I need a BCM4301
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 days when mac80211 goes into mainline. It would be easier if the donor is in the US, but not necessary. If the trade doesn't succeed, feel free to buy a Linksys WMP11 on eBay, you will get a money refund. Ok. I need the WPC11, which is the PCMCIA version. A WMP11 is a PCI card. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH 2/3] bcm43xx-mac80211: accessor functions for chip DMA capabilities.
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 30bit dma
without
keeping separate track of it.
Signed-off-by: Will Dyson [EMAIL PROTECTED]
---
.../net/wireless/mac80211/bcm43xx/bcm43xx_dma.c| 70
+---
.../net/wireless/mac80211/bcm43xx/bcm43xx_dma.h| 49 +++---
2 files changed, 70 insertions(+), 49 deletions(-)
diff --git a/drivers/net/wireless/mac80211/bcm43xx/bcm43xx_dma.c
b/drivers/net/wireless/mac80211/bcm43xx/bcm43xx_dma.c
index 4abc6c8..d09b849 100644
--- a/drivers/net/wireless/mac80211/bcm43xx/bcm43xx_dma.c
+++ b/drivers/net/wireless/mac80211/bcm43xx/bcm43xx_dma.c
@@ -418,18 +418,18 @@ static void free_ringmemory(struct bcm43xx_dmaring
*ring)
/* Reset the RX DMA channel */
int bcm43xx_dmacontroller_rx_reset(struct bcm43xx_wldev *dev,
- u16 mmio_base, int dma64)
+ u16 mmio_base)
{
int i;
u32 value;
u16 offset;
-offset = dma64 ? BCM43xx_DMA64_RXCTL : BCM43xx_DMA32_RXCTL;
+offset = bcm43xx_dma64(dev) ? BCM43xx_DMA64_RXCTL :
BCM43xx_DMA32_RXCTL;
bcm43xx_write32(dev, mmio_base + offset, 0);
for (i = 0; i 1000; i++) {
-offset = dma64 ? BCM43xx_DMA64_RXSTATUS : BCM43xx_DMA32_RXSTATUS;
+offset = bcm43xx_dma64(dev) ? BCM43xx_DMA64_RXSTATUS :
BCM43xx_DMA32_RXSTATUS;
value = bcm43xx_read32(dev, mmio_base + offset);
-if (dma64) {
+if (bcm43xx_dma64(dev)) {
value = BCM43xx_DMA64_RXSTAT;
if (value == BCM43xx_DMA64_RXSTAT_DISABLED) {
i = -1;
@@ -454,16 +454,16 @@ int bcm43xx_dmacontroller_rx_reset(struct
bcm43xx_wldev *dev,
/* Reset the RX DMA channel */
int bcm43xx_dmacontroller_tx_reset(struct bcm43xx_wldev *dev,
- u16 mmio_base, int dma64)
+ u16 mmio_base)
{
int i;
u32 value;
u16 offset;
for (i = 0; i 1000; i++) {
-offset = dma64 ? BCM43xx_DMA64_TXSTATUS : BCM43xx_DMA32_TXSTATUS;
+offset = bcm43xx_dma64(dev) ? BCM43xx_DMA64_TXSTATUS :
BCM43xx_DMA32_TXSTATUS;
value = bcm43xx_read32(dev, mmio_base + offset);
-if (dma64) {
+if (bcm43xx_dma64(dev)) {
value = BCM43xx_DMA64_TXSTAT;
if (value == BCM43xx_DMA64_TXSTAT_DISABLED ||
value == BCM43xx_DMA64_TXSTAT_IDLEWAIT ||
@@ -478,12 +478,12 @@ int bcm43xx_dmacontroller_tx_reset(struct
bcm43xx_wldev *dev,
}
udelay(10);
}
-offset = dma64 ? BCM43xx_DMA64_TXCTL : BCM43xx_DMA32_TXCTL;
+offset = bcm43xx_dma64(dev) ? BCM43xx_DMA64_TXCTL :
BCM43xx_DMA32_TXCTL;
bcm43xx_write32(dev, mmio_base + offset, 0);
for (i = 0; i 1000; i++) {
-offset = dma64 ? BCM43xx_DMA64_TXSTATUS : BCM43xx_DMA32_TXSTATUS;
+offset = bcm43xx_dma64(dev) ? BCM43xx_DMA64_TXSTATUS :
BCM43xx_DMA32_TXSTATUS;
value = bcm43xx_read32(dev, mmio_base + offset);
-if (dma64) {
+if (bcm43xx_dma64(dev)) {
value = BCM43xx_DMA64_TXSTAT;
if (value == BCM43xx_DMA64_TXSTAT_DISABLED) {
i = -1;
@@ -587,7 +587,7 @@ static int dmacontroller_setup(struct bcm43xx_dmaring
*ring)
u32 trans = ssb_dma_translation(ring-dev-dev);
if (ring-tx) {
-if (ring-dma64) {
+if (bcm43xx_dma64(ring-dev)) {
u64 ringbase = (u64)(ring-dmabase);
addrext = ((ringbase 32) SSB_DMA_TRANSLATION_MASK)
@@ -618,7 +618,7 @@ static int dmacontroller_setup(struct bcm43xx_dmaring
*ring)
err = alloc_initial_descbuffers(ring);
if (err)
goto out;
-if (ring-dma64) {
+if (bcm43xx_dma64(ring-dev)) {
u64 ringbase = (u64)(ring-dmabase);
addrext = ((ringbase 32) SSB_DMA_TRANSLATION_MASK)
@@ -659,15 +659,15 @@ out:
static void dmacontroller_cleanup(struct bcm43xx_dmaring *ring)
{
if (ring-tx) {
-bcm43xx_dmacontroller_tx_reset(ring-dev, ring-mmio_base,
ring-dma64);
-if (ring-dma64) {
+bcm43xx_dmacontroller_tx_reset(ring-dev, ring-mmio_base);
+if (bcm43xx_dma64(ring-dev)) {
bcm43xx_dma_write(ring, BCM43xx_DMA64_TXRINGLO, 0);
bcm43xx_dma_write(ring, BCM43xx_DMA64_TXRINGHI, 0);
} else
bcm43xx_dma_write(ring, BCM43xx_DMA32_TXRING, 0);
} else {
-bcm43xx_dmacontroller_rx_reset(ring-dev, ring-mmio_base,
ring-dma64);
-if (ring-dma64) {
+bcm43xx_dmacontroller_rx_reset(ring-dev, ring-mmio_base);
+if (bcm43xx_dma64(ring-dev)) {
bcm43xx_dma_write(ring, BCM43xx_DMA64_RXRINGLO, 0);
bcm43xx_dma_write(ring, BCM43xx_DMA64_RXRINGHI, 0);
} else
@@ -725,8 +725,7 @@ static u64 supported_dma_mask(struct bcm43xx_wldev *dev)
static
struct bcm43xx_dmaring *
Re: combined on 2.6.20.3
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 mac80211-based bcm43xx driver. I mean, I want to test the latest bcm43xx to see is the machine check is gone. It's quite common for somebody to wish to download, compile and install the driver without the hassle of patching the kernel, especially a vendor kernel or an embedded kernel that's hard upgrade, or a kernel that takes hours to compile. For a quickly progressing driver, having a standalone distribution could be very convenient for both users and developers. Users of exotic processors could catch the bugs x86 hides. We will need one for the day when mac80211 replaces softmac in the mainline kernel. What would we need to do? 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 version? I would say the softmac version should stay in the tree. Firstly, it supports older hardware. Secondly, it's a point of reference, which is useful until the driver is quite stable. But most importantly, bcm43xx_mac80211 has some issues that bcm43xx doesn't have. I have to disable 802.11g modes just to use it. I'm not sure if it's related, but bcm43xx_mac80211 emits this warning on startup: bcm43xx_mac80211: !WARNING! Idle-TSSI phy-cur_idle_tssi measuring failed. (cur=9, tgt=62). Disabling TX power adjustment. I'm not really an expert here, but it looks like a very hard problem to me. I just don't see any practical approach to fixing it. I don't think it can be assumed that it will just go away. Having a mac80211 driver with v3 firmware would be a first step at bisecting the bug, but I guess it would be very time consuming. On the other hand, it could replace the softmac driver eventually. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: combined on 2.6.20.3
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 working standalone driver for all supported cards. Why standalone? As long as bcm43xx-softmac is mainline, isn't that enough? I mean, many users prefer to keep the vendor kernel and compile additional modules against it. It's easier than to pick the right patch and recompile the modules. As for your machine check problem, I'll send you a trial patch to see if it fixes the problem. Thanks! I hope to test it tonight. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: combined on 2.6.20.3
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 this driver? -Joe ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: BCM4310 UART [14e4:4312] (rev 01) partly working
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 Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] bcm43xx: Fix machine check on PPC for version 1 PHY
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 for G PHY's with a revision number equal to 1. The two offending changes are reverted. I'm not sure this patch is complete. Joseph made changes to the specs that should fix the issue completely. I didn't look at the changes, yet. Joseph has fixed the problem in initb5 (the first hunk), but the second hunk is still not in the new specs. It was in the previous version in a slightly different form, but was found largely by trial and error. I would prefer that this patch go forward as is so that we don't end up with this bug in the released version of 21.6.21. I am in the process of making the initg code match the current specs, but that will certainly require more testing than I think we have time to complete before 2.6.21 is released. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
