Re: zd1211rw (2.6.26 sparc64): unaligned access (zd_mac_rx)

[Shaddy Baddah <shaddy_baddah@hotmail.com>]

On 29/11/08 09:44, Michael Buesch wrote:
> On Friday 28 November 2008 06:34:34 Shaddy Baddah wrote:
>> case the same simple function replacement would not be OK. But I saw 
>> several places where memcmp() is preferred to compare_ether_addr(), 
>> which I assume indicates that mac80211 does not expect alignment of 
>> 80211 packets passed to it.
> 
> The whole networking stack expects 4byte alignment and the driver _must_
> make sure it is this way. Either by padding a constant number of bytes at the front
> of each allocated SKB, or (if the alignment differs) use dynamic checks
> for the lowest few bits of the pointer passed to mac80211.

Right. But I'm not sure that in this case that the packet is being 
passed to mac80211 by the driver. My recall of the stack traces I saw 
were that the unalignment I was seeing in sta_info_get() were a 
consequence of transmission attempts.

I must admit though, I could not source where the unaligned packet came 
from, as I do not fully understand the different queuing mechanisms in 
use and where and how enqueues occur. My  limited efforts to understand 
this gave me the impression that network stack itself, and not the 
driver, was constructing these unaligned packets, for transmission.

The memcmp() that really persuaded me to believe that the mac80211 had 
no alignment requirements was this one:

net/mac80211/tx.c:1304:		if (memcmp(odev->dev_addr, hdr->addr4, 
ETH_ALEN) != 0)

I would have thought it would use compare_ether_addr() if we could 
safely assume alignment. In any case, say that alignment was always the 
intention... then can't we just use memcmp() as a hack (not being 
derogatory. Just that it would turn into a hack in deference to using 
compare_ether_addr()) consistent with hacks like the above? Even in the 
interim until a program to iron out alignment is set in place?

Regards,
Shaddy