[PATCH] libertas: revert CAPINFO_MASK to its original value

[Ronak Chokshi]

Dan,
Documents always tend to follow the code / implementation. There is
always a hurry to get the implementation out of the door. Only after
this, we get time to update the documents esp. the more involved ones
such as the WLAN Firmware specifications. To address the deficiencies in
the specification, you can open tickets on Trac and we will make sure
they are addressed. Just put them in the wireless distro and assign it
to me. I will re-assign it to our team lead at Marvell and it will get
done. I see that you have already started doing that, so you are doing
the right thing :).

We are also preparing an addendum document to the WLAN Firmware
specification v5.1 which will clear most of the bit-level confusions on
your side. The ETA for the first draft of this addendum should be late
this week or early next week. We can post this on the TechWiki if that
is the appropriate place for this. 

So, if you have any further confusions/questions, please keep entering
the information on the trac ticket 2177 that you have already opened and
we will keep addressing it in the document.

Thanks
Ronak

-----Original Message-----
From: Dan Williams [mailto:dcbw at redhat.com] 
Sent: Tuesday, July 17, 2007 7:00 AM
To: Luis Carlos Cobo
Cc: libertas-dev at lists.infradead.org; Ronak Chokshi; Manas Saksena
Subject: Re: [PATCH] libertas: revert CAPINFO_MASK to its original value

On Mon, 2007-07-16 at 18:57 -0700, Luis Carlos Cobo wrote:
> CAPINFO_MASK changed on commits 981f187b and a091095b. Reverting to
the original
> value.
> 
> This fixes OLPC ticket #2161
> ---
>  drivers/net/wireless/libertas/types.h |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/net/wireless/libertas/types.h
b/drivers/net/wireless/libertas/types.h
> index 2df352d..61ca4f8 100644
> --- a/drivers/net/wireless/libertas/types.h
> +++ b/drivers/net/wireless/libertas/types.h
> @@ -7,7 +7,7 @@
>  #include <linux/if_ether.h>
>  #include <asm/byteorder.h>
>  
> -#define CAPINFO_MASK	(~(0x00da))
> +#define CAPINFO_MASK	(~(0xda00))
>  
>  struct ieeetypes_cfparamset {
>  	u8 elementid;

Hmm, my fault then.  A few questions though.  What exact bits are
supposed to be passed to the firmware here, and what bits are explicitly
being masked out?  From what I can see, when NOTing the capinfo mask, we
are really AND-ing the BSS's beacon capability field with
0010010111111111 (before converting it to LE and passing to firmware).
In any case, why are certain undefined bits masked out, and what exactly
are those bits that the firmware cares about and why does it care about
those and not others?

The 5.1 specification says nothing about this.  For the capinfo field of
the IEEEtypes_BssDesc_t it says just "Firmware capability information"
and nothing beyond that.  The spec is essentially useless on these and
other questions that are necessary for adequately maintaining the driver
without direct visibility into the firmware code, which I obviously do
not have.  The firmware-as-black-box method only works when the
specification is adequate.

Ronak, for deficiencies in the specification, what's the procedure to
update the spec and get a new copy with sufficiently low turnaround?

Dan