iMX31 and 88W8686 SDIO module

[Dan Williams]

On Tue, 2008-04-29 at 12:05 +0200, Holger Schurig wrote:
> > 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.

The v8 and v9 drivers probably drop this because their hardware supports
all common rates.  The v9 moblin driver just returns a static table of
supported 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 think there's a divergence at firmware v5.1 here.  It looks like
firmware versions < 5.1 use DATA_RATE.

But 5.1 and later, while they support DATA_RATE, have transitioned
to CMD_TX_RATE_QUERY for getting the rate (SIOCGIWRATE)
and CMD_802_11_RATE_ADAPT_RATESET for setting the rate scaling table
(SIOCSIWRATE).  Both are described in the 5.1 spec and also implemented
in the moblin driver.

We'll probably have to have some firmware checking logic in the driver
to take the appropriate path.

Dan

> 
> 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.
> 
> _______________________________________________
> libertas-dev mailing list
> libertas-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libertas-dev