On Friday 14 September 2007 23:19:36 Larry Finger wrote:
> David Woodhouse wrote:
> > On Fri, 2007-09-14 at 14:05 -0500, Larry Finger wrote:
> >> Are you using DMA or PIO? I did find some PIO endian problems, but
> >> none with DMA so far.
> >
> > I don't know -- which probably means DMA, right? I don't have > 1GiB of
> > RAM (I have precisely 1GiB).
>
> Yes, I would expect that you are using DMA. Up to 1 GiB RAM has no problems.
> AFAIK, even those with
> > 1 GiB and 30-bit cards are OK.
>
> I downloaded the newest version of sparse and there are some endian issues
> with DMA. These have
> already been submitted as a patch, but are in Linville's inbox while he
> catches up. I have attached
> a copy of that patch for you. It should be applied on top of the patch sent
> earlier today.
These are all false positives, except this one, where the wrong
converter function was used.
@@ -442,7 +444,7 @@ void b43legacy_rx(struct b43legacy_wldev
phystat0 = le16_to_cpu(rxhdr->phy_status0);
phystat3 = le16_to_cpu(rxhdr->phy_status3);
jssi = rxhdr->jssi;
- macstat = le32_to_cpu(rxhdr->mac_status);
+ macstat = le16_to_cpu(rxhdr->mac_status);
mactime = le16_to_cpu(rxhdr->mac_time);
chanstat = le16_to_cpu(rxhdr->channel);
But I think in this case this also didn't change the actual
result in macstat.
le32_to_cpu would take the lower two bytes of rxhdr->maxstatus
and put them into 0xDDCCBBAA. Where DD and CC are some "random" value.
That value is casted to u16 then
so we end up with 0xBBAA. The upper two bytes will be discarded.
The le16_to_cpu would take the lower two bytes and correctly
convert them to 0xBBAA.
--
Greetings Michael.
_______________________________________________
Bcm43xx-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
