Search Linux Wireless

Re: pci_set_mwi() and ath5k

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



2009/11/5 Luis R. Rodriguez <mcgrof@xxxxxxxxx>:
>
> There are two cases where we can use the PCI_CACHE_LINE_SIZE:
>
> 1) Hardware has been designed to use it on some block to align some data somehow
> 2) Software uses it to align skb->data for performance/hw purposes
>
> I believe the second case can be handled by using L1_CACHE_BYTES
> instead and I'd at least like to change our common skb allocator to
> use that.
>
> The first case is where it seems there may be some skepticism as to
> whether or not hw really did not rely on it and I agree its safer to
> keep the programming of the  PCI_CACHE_LINE_SIZE in case it has a
> bogus value.
>
> Does this seem reasonable?
>
>  Luis
>

Yup, i believe 2 is the case, from what i've read the problem is that
we get corrupted data so i guess we can just use the L1_CACHE_BYTES to
align skb->data and not write anything to PCI_CACHE_LINE_SIZE if you
think that will work. Just be sure to test on some ath5k cards (don't
have time for anything right now ;-( ). I believe having cleaner code
is better than supporting an ancient chip anyway, if this is really
necessary for AR5210 -writing PCI_CACHE_LINE_SIZE- we can deal with it
later.

-- 
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux