[PATCH] libertas: revert CAPINFO_MASK to its original value

[Dan Williams]

On Tue, 2007-07-17 at 09:20 -0700, Javier Cardona wrote:
> Dan,
> 
> > 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?
> 
> That is the Capability Information field, as defined in sect 7.3.1.4
> of the standard.  The mask is clearing bits 8, 9, 11, 12 and 14, which
> translates to the following capabilities: Spectrum Management, QoS,
> Automatic Power Save Delivery, Delayed Block Acks (and b12, which is
> reserved by the standard and should be zeroed).

Ok, so it's supposed to keep _all_ lower 8 bits:

0 - ESS
1 - IBSS
2 - CF Pollable
3 - CF Poll Request
4 - Privacy
5 - Short Preamble
6 - PBCC
7 - Channel Agility

and clear 8, 9, 11, 12, and 14?

> If the endianness of the mask is reversed, as Luisca pointed out, the
> IBSS capability is disabled, explaining why joins were failing.

But on the host, it shouldn't _matter_ what the endianness of the mask
is.  The capability is converted to cpu byte order when it's read out of
the beacon response field, so AND-ing the cpu-order capability with
~0xda00 and then converting to LE when writing to the join/assoc command
should be sufficient, right?

The problem here is that it wasn't really clear what the mask was
supposed to do, and therefore I assumed that we wished to mask out some
of the lower 8 bits of the capability with the problem patch, because
those are the bits defined by the 802.11b standard.  It didn't have
anything to do with endianness, because endianness doesn't matter for
the capability field any more, because any operations should _always_ be
in host cpu byte order until immediately before it's written to the
card.

Dan

> > 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.
> 
> I agree that the spec should point to the relevant section on the standard.
> 
> > (...)
> 
> I'll let others respond on the spec update procedure.
> 
> Cheers,
> 
> Javier