[PATCH 0/3] b43 & bcma: DMA special (translation) bits

[PATCH 0/3] b43 & bcma: DMA special (translation) bits

[Rafał Miłecki]

Thanks to Pavel's comments I digged into translation bits and found out
the hackish way we currently use to handle 32-bit and 64-bit DMA.

I've replaced out bit shifting hacks with just a one, documented in the
comment. This workaround ideally should be just fixed, but I'm not going
to blidly change the current behaviour of ssb_dma_translation without
testing that with b43legacy and b44. As I don't have such a hardware,
we will need to find some testers.

In any case, the way we changed the code should be correct. When ssb
function will be fixed, b43 will only require deletion of 2 code lines.

I've tested this code for regressions on my following cards:
1) 14e4:432b (64-bit DMA)
2) 14e4:4315 (64-bit DMA)
3) 14e4:4312 (32-bit DMA)
Transmission is still possible on all of them, no errors were noticed.


Pavel: sorry for CC-ing you with my previous serie. Fortunately this
lead to the much nicer solution, thanks for your help.
I let myself yo CC you once more, as this patch serie tries to fix
issues you pointed to me.

Rafa? Mi?ecki (3):
  b43: replace DMA translation workarounds with just a one, commented
  bcma: inform drivers about translation bits needed for the core
  b43: bcma: get DMA translation bits

 drivers/bcma/core.c            |   16 ++++++++++++++++
 drivers/net/wireless/b43/dma.c |   17 ++++++++++++++---
 drivers/net/wireless/b43/dma.h |    4 ++++
 include/linux/bcma/bcma.h      |    5 +++++
 4 files changed, 39 insertions(+), 3 deletions(-)

-- 
1.7.3.4

[PATCH 1/3] b43: replace DMA translation workarounds with just a one, commented

[Rafał Miłecki]

Routing bits are always placed in 0xC0000000, there is no any special
bit shifting for 64-bit DMA. We just workaround wrong value (passed by
ssb) in this way. Replace that with just a one workaround and comment
it. Real fix for this requires testing with all ssb drivers.

Signed-off-by: Rafa? Mi?ecki <zajec5@gmail.com>
---
 drivers/net/wireless/b43/dma.c |   12 +++++++++---
 1 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/b43/dma.c b/drivers/net/wireless/b43/dma.c
index ce572ae..530a153 100644
--- a/drivers/net/wireless/b43/dma.c
+++ b/drivers/net/wireless/b43/dma.c
@@ -174,7 +174,7 @@ static void op64_fill_descriptor(struct b43_dmaring *ring,
 	addrhi = (((u64) dmaaddr >> 32) & ~SSB_DMA_TRANSLATION_MASK);
 	addrext = (((u64) dmaaddr >> 32) & SSB_DMA_TRANSLATION_MASK)
 	    >> SSB_DMA_TRANSLATION_SHIFT;
-	addrhi |= (ring->dev->dma.translation << 1);
+	addrhi |= ring->dev->dma.translation;
 	if (slot == ring->nr_slots - 1)
 		ctl0 |= B43_DMA64_DCTL0_DTABLEEND;
 	if (start)
@@ -675,7 +675,7 @@ static int dmacontroller_setup(struct b43_dmaring *ring)
 			b43_dma_write(ring, B43_DMA64_TXRINGHI,
 				      ((ringbase >> 32) &
 				       ~SSB_DMA_TRANSLATION_MASK)
-				      | (trans << 1));
+				      | trans);
 		} else {
 			u32 ringbase = (u32) (ring->dmabase);
 
@@ -708,7 +708,7 @@ static int dmacontroller_setup(struct b43_dmaring *ring)
 			b43_dma_write(ring, B43_DMA64_RXRINGHI,
 				      ((ringbase >> 32) &
 				       ~SSB_DMA_TRANSLATION_MASK)
-				      | (trans << 1));
+				      | trans);
 			b43_dma_write(ring, B43_DMA64_RXINDEX, ring->nr_slots *
 				      sizeof(struct b43_dmadesc64));
 		} else {
@@ -1060,6 +1060,12 @@ int b43_dma_init(struct b43_wldev *dev)
 #ifdef CONFIG_B43_SSB
 	case B43_BUS_SSB:
 		dma->translation = ssb_dma_translation(dev->dev->sdev);
+		/* ssb does not handle 64-bit DMA case, where Client Mode
+		 * Translation is set with value 0x2 instead of 0x1. This should
+		 * be fixed on ssb side, but requires testing with b43,
+		 * b43legacy and b44. */
+		if (b43_read32(dev, SSB_TMSHIGH) & SSB_TMSHIGH_DMA64)
+			dma->translation <<= 1;
 		break;
 #endif
 	}
-- 
1.7.3.4

[PATCH 2/3] bcma: inform drivers about translation bits needed for the core

[Rafał Miłecki]

When using DMA, drivers need to pass special translation info to the
hardware.

Signed-off-by: Rafa? Mi?ecki <zajec5@gmail.com>
---
 drivers/bcma/core.c       |   16 ++++++++++++++++
 include/linux/bcma/bcma.h |    5 +++++
 2 files changed, 21 insertions(+), 0 deletions(-)

diff --git a/drivers/bcma/core.c b/drivers/bcma/core.c
index 2d8506d..4a04a49 100644
--- a/drivers/bcma/core.c
+++ b/drivers/bcma/core.c
@@ -106,3 +106,19 @@ void bcma_core_pll_ctl(struct bcma_device *core, u32 req, u32 status, bool on)
 	}
 }
 EXPORT_SYMBOL_GPL(bcma_core_pll_ctl);
+
+u32 bcma_core_dma_translation(struct bcma_device *core)
+{
+	switch (core->bus->hosttype) {
+	case BCMA_HOSTTYPE_PCI:
+		if (bcma_aread32(core, BCMA_IOST) & BCMA_IOST_DMA64)
+			return BCMA_DMA_TRANSLATION_DMA64_CMT;
+		else
+			return BCMA_DMA_TRANSLATION_DMA32_CMT;
+	default:
+		pr_err("DMA translation unknown for host %d\n",
+		       core->bus->hosttype);
+	}
+	return BCMA_DMA_TRANSLATION_NONE;
+}
+EXPORT_SYMBOL(bcma_core_dma_translation);
diff --git a/include/linux/bcma/bcma.h b/include/linux/bcma/bcma.h
index cc1582d..8c96654 100644
--- a/include/linux/bcma/bcma.h
+++ b/include/linux/bcma/bcma.h
@@ -262,5 +262,10 @@ extern void bcma_core_set_clockmode(struct bcma_device *core,
 				    enum bcma_clkmode clkmode);
 extern void bcma_core_pll_ctl(struct bcma_device *core, u32 req, u32 status,
 			      bool on);
+#define BCMA_DMA_TRANSLATION_MASK	0xC0000000
+#define  BCMA_DMA_TRANSLATION_NONE	0x00000000
+#define  BCMA_DMA_TRANSLATION_DMA32_CMT	0x40000000 /* Client Mode Translation for 32-bit DMA */
+#define  BCMA_DMA_TRANSLATION_DMA64_CMT	0x80000000 /* Client Mode Translation for 64-bit DMA */
+extern u32 bcma_core_dma_translation(struct bcma_device *core);
 
 #endif /* LINUX_BCMA_H_ */
-- 
1.7.3.4

[PATCH 3/3] b43: bcma: get DMA translation bits

[Rafał Miłecki]

Add some missing defines by the way.

Signed-off-by: Rafa? Mi?ecki <zajec5@gmail.com>
---
 drivers/net/wireless/b43/dma.c |    5 +++++
 drivers/net/wireless/b43/dma.h |    4 ++++
 2 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/drivers/net/wireless/b43/dma.c b/drivers/net/wireless/b43/dma.c
index 530a153..0a5004b 100644
--- a/drivers/net/wireless/b43/dma.c
+++ b/drivers/net/wireless/b43/dma.c
@@ -1057,6 +1057,11 @@ int b43_dma_init(struct b43_wldev *dev)
 		return err;
 
 	switch (dev->dev->bus_type) {
+#ifdef CONFIG_B43_BCMA
+	case B43_BUS_BCMA:
+		dma->translation = bcma_core_dma_translation(dev->dev->bdev);
+		break;
+#endif
 #ifdef CONFIG_B43_SSB
 	case B43_BUS_SSB:
 		dma->translation = ssb_dma_translation(dev->dev->sdev);
diff --git a/drivers/net/wireless/b43/dma.h b/drivers/net/wireless/b43/dma.h
index e8a80a1..cdf8709 100644
--- a/drivers/net/wireless/b43/dma.h
+++ b/drivers/net/wireless/b43/dma.h
@@ -20,6 +20,7 @@
 #define		B43_DMA32_TXSUSPEND			0x00000002
 #define		B43_DMA32_TXLOOPBACK		0x00000004
 #define		B43_DMA32_TXFLUSH			0x00000010
+#define		B43_DMA32_TXPARITYDISABLE		0x00000800
 #define		B43_DMA32_TXADDREXT_MASK		0x00030000
 #define		B43_DMA32_TXADDREXT_SHIFT		16
 #define B43_DMA32_TXRING				0x04
@@ -44,6 +45,7 @@
 #define		B43_DMA32_RXFROFF_MASK		0x000000FE
 #define		B43_DMA32_RXFROFF_SHIFT		1
 #define		B43_DMA32_RXDIRECTFIFO		0x00000100
+#define		B43_DMA32_RXPARITYDISABLE		0x00000800
 #define		B43_DMA32_RXADDREXT_MASK		0x00030000
 #define		B43_DMA32_RXADDREXT_SHIFT		16
 #define B43_DMA32_RXRING				0x14
@@ -84,6 +86,7 @@ struct b43_dmadesc32 {
 #define		B43_DMA64_TXSUSPEND			0x00000002
 #define		B43_DMA64_TXLOOPBACK		0x00000004
 #define		B43_DMA64_TXFLUSH			0x00000010
+#define		B43_DMA64_TXPARITYDISABLE		0x00000800
 #define		B43_DMA64_TXADDREXT_MASK		0x00030000
 #define		B43_DMA64_TXADDREXT_SHIFT		16
 #define B43_DMA64_TXINDEX				0x04
@@ -111,6 +114,7 @@ struct b43_dmadesc32 {
 #define		B43_DMA64_RXFROFF_MASK		0x000000FE
 #define		B43_DMA64_RXFROFF_SHIFT		1
 #define		B43_DMA64_RXDIRECTFIFO		0x00000100
+#define		B43_DMA64_RXPARITYDISABLE		0x00000800
 #define		B43_DMA64_RXADDREXT_MASK		0x00030000
 #define		B43_DMA64_RXADDREXT_SHIFT		16
 #define B43_DMA64_RXINDEX				0x24
-- 
1.7.3.4

[PATCH 1/3] b43: replace DMA translation workarounds with just a one, commented

[Larry Finger]

On 07/19/2011 05:12 PM, Rafa? Mi?ecki wrote:
> Routing bits are always placed in 0xC0000000, there is no any special
> bit shifting for 64-bit DMA. We just workaround wrong value (passed by
> ssb) in this way. Replace that with just a one workaround and comment
> it. Real fix for this requires testing with all ssb drivers.

If you wish to supply the real patch, I can test b43legacy.

Larry

[PATCH 1/3] b43: replace DMA translation workarounds with just a one, commented

[Michael Büsch]

On Wed, 20 Jul 2011 00:12:20 +0200
Rafa? Mi?ecki <zajec5@gmail.com> wrote:
> +		 * be fixed on ssb side, but requires testing with b43,
> +		 * b43legacy and b44. */

No it doesn't. b44 and b43legacy don't use 64bit DMA.
Just fix it in ssb, please.

[PATCH 1/3] b43: replace DMA translation workarounds with just a one, commented

[Rafał Miłecki]

W dniu 20 lipca 2011 01:15 u?ytkownik Michael B?sch <m@bues.ch> napisa?:
> On Wed, 20 Jul 2011 00:12:20 +0200
> Rafa? Mi?ecki <zajec5@gmail.com> wrote:
>> + ? ? ? ? ? ? ?* be fixed on ssb side, but requires testing with b43,
>> + ? ? ? ? ? ? ?* b43legacy and b44. */
>
> No it doesn't. b44 and b43legacy don't use 64bit DMA.
> Just fix it in ssb, please.

They (drivers) don't, but what if we start giving them routing for
64-bit DMA? AFAIU they treat 64-bit DMA as 32-bit one (according to
specs: "If 64 Bit isn't an option, Silicon Backplane and PCI-E buses
can use 32 bit DMA.").

Won't they start using 64-bit DMA in the 32-bit way but with 64-bit
routing bits?

-- 
Rafa?

[PATCH 1/3] b43: replace DMA translation workarounds with just a one, commented

[Larry Finger]

On 07/20/2011 01:16 AM, Rafa? Mi?ecki wrote:
> W dniu 20 lipca 2011 01:15 u?ytkownik Michael B?sch<m@bues.ch>  napisa?:
>> On Wed, 20 Jul 2011 00:12:20 +0200
>> Rafa? Mi?ecki<zajec5@gmail.com>  wrote:
>>> +              * be fixed on ssb side, but requires testing with b43,
>>> +              * b43legacy and b44. */
>>
>> No it doesn't. b44 and b43legacy don't use 64bit DMA.
>> Just fix it in ssb, please.
>
> They (drivers) don't, but what if we start giving them routing for
> 64-bit DMA? AFAIU they treat 64-bit DMA as 32-bit one (according to
> specs: "If 64 Bit isn't an option, Silicon Backplane and PCI-E buses
> can use 32 bit DMA.").
>
> Won't they start using 64-bit DMA in the 32-bit way but with 64-bit
> routing bits?

The BCM4311 was the first device that supported 64-bit DMA. I had the first of 
those, and I got to debug the 64-bit stuff that had been written by Michael, but 
there had been no hardware for testing. All earlier devices were restricted to 
32-bit paths.

Larry

[PATCH 1/3] b43: replace DMA translation workarounds with just a one, commented

[Michael Büsch]

On Wed, 20 Jul 2011 08:16:08 +0200
Rafa? Mi?ecki <zajec5@gmail.com> wrote:

> W dniu 20 lipca 2011 01:15 u?ytkownik Michael B?sch <m@bues.ch> napisa?:
> > On Wed, 20 Jul 2011 00:12:20 +0200
> > Rafa? Mi?ecki <zajec5@gmail.com> wrote:
> >> + ? ? ? ? ? ? ?* be fixed on ssb side, but requires testing with b43,
> >> + ? ? ? ? ? ? ?* b43legacy and b44. */
> >
> > No it doesn't. b44 and b43legacy don't use 64bit DMA.
> > Just fix it in ssb, please.
> 
> They (drivers) don't, but what if we start giving them routing for
> 64-bit DMA? AFAIU they treat 64-bit DMA as 32-bit one (according to
> specs: "If 64 Bit isn't an option, Silicon Backplane and PCI-E buses
> can use 32 bit DMA.").
> 
> Won't they start using 64-bit DMA in the 32-bit way but with 64-bit
> routing bits?
> 

I have no idea what you're talking about.
The fact is: These "temporary workarounds" tend to stay in the driver forever
if we don't fix it _now_. So please fix it now.
We know whether we are on 64bit DMA or not. So if we are on 64bit DMA, use the 64bit mask.
Simply pass the "32 or 64 bit" boolean flag to ssb_dma_translation() as parameter.
There's nothing that can go wrong here with older drivers.

[PATCH 1/3] b43: replace DMA translation workarounds with just a one, commented

[Rafał Miłecki]

On Jul 20, 2011 10:55 AM, "Michael B?sch" <m@bues.ch> wrote:
>
> On Wed, 20 Jul 2011 08:16:08 +0200
> Rafa? Mi?ecki <zajec5@gmail.com> wrote:
>
> > W dniu 20 lipca 2011 01:15 u?ytkownik Michael B?sch <m@bues.ch> napisa?:
> > > On Wed, 20 Jul 2011 00:12:20 +0200
> > > Rafa? Mi?ecki <zajec5@gmail.com> wrote:
> > >> + ? ? ? ? ? ? ?* be fixed on ssb side, but requires testing with b43,
> > >> + ? ? ? ? ? ? ?* b43legacy and b44. */
> > >
> > > No it doesn't. b44 and b43legacy don't use 64bit DMA.
> > > Just fix it in ssb, please.
> >
> > They (drivers) don't, but what if we start giving them routing for
> > 64-bit DMA? AFAIU they treat 64-bit DMA as 32-bit one (according to
> > specs: "If 64 Bit isn't an option, Silicon Backplane and PCI-E buses
> > can use 32 bit DMA.").
> >
> > Won't they start using 64-bit DMA in the 32-bit way but with 64-bit
> > routing bits?
> >
>
> I have no idea what you're talking about.
> The fact is: These "temporary workarounds" tend to stay in the driver forever
> if we don't fix it _now_. So please fix it now.
> We know whether we are on 64bit DMA or not. So if we are on 64bit DMA, use the 64bit mask.
> Simply pass the "32 or 64 bit" boolean flag to ssb_dma_translation() as parameter.
> There's nothing that can go wrong here with older drivers.

Sorry, for not explaining this well eno
ugh. I'm afraid of situation where b44 driver supports 64-bit DMA
device *without* handling this as such a device. It treats it as
32-bit one and it works thanks to kind of ssb's fallback described in
the specs. Now if I clean ssb_dma_translation we will detect that DMA
is 64-bit and we will pass different routing bit.

So as the result b44 will still treat DMA as 32-bit one, but it will
start using routing for 64-bit one.
Alternative is to do not detect kind of DMA in the ssb_dma_translation
but take it as a parameter (as you suggested). A *little* more to care
about on the driver side but would make a trick.

Or... is there any b44 supported device with 64-bit DMA at all?


-- 
Rafa?

[PATCH 1/3] b43: replace DMA translation workarounds with just a one, commented

[Michael Büsch]

On Wed, 20 Jul 2011 13:10:55 +0200
Rafa? Mi?ecki <zajec5@gmail.com> wrote:

> Sorry, for not explaining this well eno
> ugh. I'm afraid of situation where b44 driver supports 64-bit DMA
> device *without* handling this as such a device. 

A b44 or b43legacy device with 64bit DMA engine does not exist.

[PATCH 1/3] b43: replace DMA translation workarounds with just a one, commented

[Rafał Miłecki]

2011/7/21 Pavel Roskin <proski@gnu.org>:
> On 07/20/2011 11:35 AM, Michael B?sch wrote:
>>
>> On Wed, 20 Jul 2011 13:10:55 +0200
>> Rafa? Mi?ecki<zajec5@gmail.com> ?wrote:
>>
>>> Sorry, for not explaining this well eno
>>> ugh. I'm afraid of situation where b44 driver supports 64-bit DMA
>>> device *without* handling this as such a device.
>>
>> A b44 or b43legacy device with 64bit DMA engine does not exist.
>
> There are many references to "B43legacy_DMA_64BIT" and "dma64_ops" in
> b43legacy. ?I guess they all are unneeded, and so is struct
> b43legacy_dma_ops.
>
> b44 doesn't seem to have DMA64 support. ?By the way, the result of
> ssb_dma_translation() is placed into bp->dma_offset. ?I think the word
> "offset" is misleading.

Thanks for comment. I didn't have any time to review (&clean?)
b43legacy, not to mention b44. Unfortunately I'm too busy with b43
stuff for now. If you have some free time, you're input to the drivers
is welcome :)

-- 
Rafa?

[PATCH 1/3] b43: replace DMA translation workarounds with just a one, commented

[Michael Büsch]

On Thu, 21 Jul 2011 17:33:51 +0200
Rafa? Mi?ecki <zajec5@gmail.com> wrote:

> 2011/7/21 Pavel Roskin <proski@gnu.org>:
> > On 07/20/2011 11:35 AM, Michael B?sch wrote:
> >>
> >> On Wed, 20 Jul 2011 13:10:55 +0200
> >> Rafa? Mi?ecki<zajec5@gmail.com> ?wrote:
> >>
> >>> Sorry, for not explaining this well eno
> >>> ugh. I'm afraid of situation where b44 driver supports 64-bit DMA
> >>> device *without* handling this as such a device.
> >>
> >> A b44 or b43legacy device with 64bit DMA engine does not exist.
> >
> > There are many references to "B43legacy_DMA_64BIT" and "dma64_ops" in
> > b43legacy. ?I guess they all are unneeded, and so is struct
> > b43legacy_dma_ops.
> >
> > b44 doesn't seem to have DMA64 support. ?By the way, the result of
> > ssb_dma_translation() is placed into bp->dma_offset. ?I think the word
> > "offset" is misleading.
> 
> Thanks for comment. I didn't have any time to review (&clean?)
> b43legacy, not to mention b44. Unfortunately I'm too busy with b43
> stuff for now. If you have some free time, you're input to the drivers
> is welcome :)
> 

For historical reasons there is unused 64bit dma code in b43legacy. I'm not sure whether it would even work. Probably not. Larry's fixes were most likely not ported over.

[PATCH 1/3] b43: replace DMA translation workarounds with just a one, commented

[Michael Büsch]

On Thu, 21 Jul 2011 19:34:40 +0000
Michael B?sch <m@bues.ch> wrote:
> For historical reasons there is unused 64bit dma code in b43legacy. I'm not sure whether it would even work. Probably not. Larry's fixes were most likely not ported over.

So I looked closer at the code now.
The b43legacy 64bit DMA code certainly is dead, unused and broken code.
One could remove it, if someone really cares (I don't).

However, there is another issue.
b43legacy calls ssb_dma_translation() (also on 30/32bit code) for every descriptor.
As our ssb patch adds a SSB register read to ssb_dma_translation(), this adds an unacceptable
amount of overhead. This needs to be addressed before merging the ssb patch.

[PATCH 1/3] b43: replace DMA translation workarounds with just a one, commented

[Rafał Miłecki]

2011/7/21 Michael B?sch <m@bues.ch>:
> On Thu, 21 Jul 2011 19:34:40 +0000
> Michael B?sch <m@bues.ch> wrote:
>> For historical reasons there is unused 64bit dma code in b43legacy. I'm not sure whether it would even work. Probably not. Larry's fixes were most likely not ported over.
>
> So I looked closer at the code now.
> The b43legacy 64bit DMA code certainly is dead, unused and broken code.
> One could remove it, if someone really cares (I don't).
>
> However, there is another issue.
> b43legacy calls ssb_dma_translation() (also on 30/32bit code) for every descriptor.
> As our ssb patch adds a SSB register read to ssb_dma_translation(), this adds an unacceptable
> amount of overhead. This needs to be addressed before merging the ssb patch.

Good catch, thanks.

As I can see, John has already took my patch. Some time has passed
without anyone noticing real problems, so I'm feeling myself the one
to blame.

Don't you mind if I prepare improvement (AKA fix) for b43legacy and
just post it today? Would that be acceptable? Or should we really
revert my latest patches? Is that a really better solution?

-- 
Rafa?

[PATCH 1/3] b43: replace DMA translation workarounds with just a one, commented

[Michael Büsch]

On Thu, 21 Jul 2011 23:31:24 +0200
Rafa? Mi?ecki <zajec5@gmail.com> wrote:
> Don't you mind if I prepare improvement (AKA fix) for b43legacy and
> just post it today?

Yeah that's OK, of course. It just needs to go in before it hits lots
of users.

-- 
Greetings, Michael.

[PATCH 1/3] b43: replace DMA translation workarounds with just a one, commented

[Larry Finger]

On 07/21/2011 04:40 PM, Michael B?sch wrote:
> On Thu, 21 Jul 2011 23:31:24 +0200
> Rafa? Mi?ecki<zajec5@gmail.com>  wrote:
>> Don't you mind if I prepare improvement (AKA fix) for b43legacy and
>> just post it today?
>
> Yeah that's OK, of course. It just needs to go in before it hits lots
> of users.

I agree that you should fix b43leagacy and leave the ssb patch alone.

Sorry that I did not get a chance to test the code, even though I promised I 
would. I've been busy figuring out what firmware is needed for 802.11 core 
revisions > 16.

Larry

[PATCH 1/3] b43: replace DMA translation workarounds with just a one, commented

[Michael Büsch]

On Sat, 23 Jul 2011 03:42:17 -0400
Pavel Roskin <proski@gnu.org> wrote:

> On 07/21/2011 03:34 PM, Michael B?sch wrote:
> 
> > For historical reasons there is unused 64bit dma code in b43legacy. I'm not sure whether it would even work. Probably not. Larry's fixes were most likely not ported over.
> 
> I tried cleaning it up and found something more interesting in process:
> 
> b43legacy_dma_write(ring, B43legacy_DMA32_RXINDEX, 200);
> 
> Comparing to b43, that 200 is supposed to be
> 
> ring->nr_slots * sizeof(struct b43_dmadesc32)
> 
> For Rx, ring->nr_slots is 64 (B43legacy_RXRING_SLOTS).
> 
> sizeof(struct b43_dmadesc32) is 8.  That gives 512 or 0x200, not the 
> decimal 200!
> 
> I have no idea what kind of effect it can have of the driver.

It doesn't have a significant effect. However, you may fix it if
you want. The number of TX descriptor slots was also lowered in b43.
b43legacy still has the old value. You may change that, too, if you want.
There may be more fixes that were not ported over. However, none of
these should be significant.

-- 
Greetings, Michael.