iMX31 and 88W8686 SDIO module

[Holger Schurig]

> libertas cmd: GET_HW_SPEC: firmware release 9.70.3p18
> libertas cmd: GET_HW_SPEC: MAC addr 00:19:88:05:39:58
> libertas cmd: GET_HW_SPEC: hardware interface 0x2, hardware
> spec 0x0011

Ahh, nice. As a side note: my firmware has 5.0.16p0. The firmware 
for the USB dongle is also at 5.x.x.x. Your firmware with 
9.x.x.px seems quite far away in it's numbering scheme.


> libertas host: DNLD_CMD: command 0x0022, size 26, jiffies
> 16367
> libertas DNLD_CMD: 22 00 1a 00 04 00 00 00 02 00 00 00 00 00
> 00 00
> libertas DNLD_CMD: 00 00 00 00 00 00 00 00 00 00

This is equivalent to the kernel libertas driver, we just have a 
different sequence number (which is OK).

cmd: DNLD_CMD: command 0x0022, seq 3, size 26
DNLD_CMD: 22 00 1a 00 03 00 00 00 02 00 00 00 00 00 00 00
DNLD_CMD: 00 00 00 00 00 00 00 00 00 00

According to the kernel libertas driver, ("grep 0022 *.h") this 
is CMD_802_11_DATA_RATE. The driver uses it to get all available 
data rates.

However, the firmware spec that was published on the mailing list 
by accident (and greatly help Marvell to get a wide adoption of 
it's hardware by the Linux community!) doesn't document command 
0x0022. Maybe your firmware, which has a much higher version 
than mine, doesn't support this command anymore. It even says 
so, error code 0x0002 is "Command not supported".


I have two suggestions:

* Try to get a full moblin image and search there 
in /lib/firmware for the firmware that suits the driver.

* or ditch lbs_get_data_rate() and implement your own, maybe by 
providing a fixed list. And for lbs_set_data_rate(), you could 
just "return -ENOPERM" or whatever for now. It's only ever 
called if the user runs "iwconfig eth1 rate XXX" anyway. The 
real solution (and one that you could contribute back the linux 
community) would be a check for the firmware version and act 
accordingly.

We might even think about getting rid of lbs_get_data_rate() 
generally, independend from the firmware version. After all, 
firmware capability bit mask from CMD_GET_HW_SPEC tells us if 
the device is 802.11b, .11g or .11a or a combination thereof. So 
we can deduce the valid data rates from the capability bits.

If you provide such a patch, I'm happy to test this on CF and an 
older USB firmware.