DV> > For supported and optional rate, IE (info element) format may be the
best DV> > choice.
DV>
DV> I did not quite understand you, can you elaborate a bit?
How card know what rates it can use? It parses "supported rates" IE (info
element) from beacon it gets from AP. My point, it is reasonable to use the
same language to specify further restrictions. This way, we will speak the
same language as standard do.
In standard, there is no way to say "you can use PBCC, but not for rate 5.5".
PBCC is either permitted or not. For "good" hardware, there is no point of
doing this. You may need to artificially restrict rate/modulation only if
hardware can't find best for current channel conditions, or, of course, for
debug. But, I would say, for this cases, let's use debug hooks. Mainline
should be as close to standard as possible.
It should be as generic as possible, also. Scheme you suggested is not very
scalable. Think of TGn that would for sure add its tricks with modulation. If
we start combining rate with modulation, we will shortly fall into too many
options.
Does it clarify my point?
pgpinrLbGzSkE.pgp
Description: PGP signature
|