On 09/09/2011 07:05 AM, Semigod King wrote:
> Larry,
> Thank you for looking at this issue. I will try your code change tonight and let
> you know test results. I have an openwrt cross build system ready on my freebsd
> at home.
That will not change a thing. Other than trip some sparse warnings,
le32_to_cpu() and cpu_to_le32() do the same thing. On little-endian boxes, they
are a no-op, and on big-endian platforms, they both reverse the byte order.
Switching the call only makes it clearer what is happening.
I am having trouble getting Ubuntu 11.04 running on my Macbook. The OS is
installed, but no X at the moment.
BTW, please do not drop the Cc to wireless. I want to keep the ML in the loop.
Larry
On 09/09/2011 12:30 PM, Semigod King wrote:
> I noticed two lines of code:
> static const u32 wcid[2] = { 0xffffffff, 0x00ffffff };
> rt2800_register_multiwrite(rt2x00dev, MAC_WCID_ENTRY(i),
> wcid, sizeof(wcid));
>
> Do you think the first line should be changed as below to eliminate
> platform difference?
> static const u32 wcid[2] = { 0xffffffff,
> cpu_to_le32(0x00ffffff) };
No, that kind of thing should not be done. Internal data that are not
specifically set to be little- or big-endian should be in cpu order. The
conversions need to be done when writing to or reading from the device when the
order differs from that of the cpu.
The changes were minimal. Most of the time it took me were in getting Linux
running on my Powerbook G4 and getting the code to compile - I had to work
around a bug in gcc version 4.4.5 on the PowerMac platform. The patch I needed
is attached. The performance of rt2800usb is not great. With netperf, I'm
getting about 5 Mbps for the netperf MAERTS, STREAM, and SENDFILE tests.
Larry
Larry,
Thanks for your work. It seems the driver works with your dongle &
platform. In your patch, the code changes are just refactor besides
efuse reading part. I tried your patch, no luck. Any r/w operation to
the card causes segment fault.
For changing
static const u32 wcid[2] = { 0xffffffff, 0x00ffffff };
to
static const u32 wcid[2] = { 0xffffffff, cpu_to_le32(0x00ffffff) };
, my understanding is that rt2800_register_multiwrite always write
data with assumption that the data is little-endian.
I have no other big-endian platform to test the driver on with regular
linux. So, i have to stick to Brcm6358 based wireless router and
openwrt.
On Thu, Sep 15, 2011 at 5:22 AM, Larry Finger <[email protected]> wrote:
> On 09/09/2011 12:30 PM, Semigod King wrote:
>>
>> I noticed two lines of code:
>> static const u32 wcid[2] = { 0xffffffff, 0x00ffffff };
>> rt2800_register_multiwrite(rt2x00dev, MAC_WCID_ENTRY(i),
>> wcid, sizeof(wcid));
>>
>> Do you think the first line should be changed as below to eliminate
>> platform difference?
>> static const u32 wcid[2] = { 0xffffffff,
>> cpu_to_le32(0x00ffffff) };
>
> No, that kind of thing should not be done. Internal data that are not
> specifically set to be little- or big-endian should be in cpu order. The
> conversions need to be done when writing to or reading from the device when
> the order differs from that of the cpu.
>
> The changes were minimal. Most of the time it took me were in getting Linux
> running on my Powerbook G4 and getting the code to compile - I had to work
> around a bug in gcc version 4.4.5 on the PowerMac platform. The patch I
> needed is attached. The performance of rt2800usb is not great. With netperf,
> I'm getting about 5 Mbps for the netperf MAERTS, STREAM, and SENDFILE tests.
>
> Larry
>
>
>
I noticed two lines of code:
static const u32 wcid[2] = { 0xffffffff, 0x00ffffff };
rt2800_register_multiwrite(rt2x00dev, MAC_WCID_ENTRY(i),
wcid, sizeof(wcid));
Do you think the first line should be changed as below to eliminate
platform difference?
static const u32 wcid[2] = { 0xffffffff,
cpu_to_le32(0x00ffffff) };
On Fri, Sep 9, 2011 at 9:55 PM, Larry Finger <[email protected]> wrote:
> On 09/09/2011 07:05 AM, Semigod King wrote:
>>
>> Larry,
>> Thank you for looking at this issue. I will try your code change tonight
>> and let
>> you know test results. I have an openwrt cross build system ready on my
>> freebsd
>> at home.
>
> That will not change a thing. Other than trip some sparse warnings,
> le32_to_cpu() and cpu_to_le32() do the same thing. On little-endian boxes,
> they are a no-op, and on big-endian platforms, they both reverse the byte
> order. Switching the call only makes it clearer what is happening.
>
> I am having trouble getting Ubuntu 11.04 running on my Macbook. The OS is
> installed, but no X at the moment.
>
> BTW, please do not drop the Cc to wireless. I want to keep the ML in the
> loop.
>
> Larry
>
>