[PATCH] libertas: revert CAPINFO_MASK to its original value

[Dan Williams]

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