On 8/6/07, Pavel Roskin <[EMAIL PROTECTED]> wrote: > On Sun, 2007-08-05 at 12:18 +0200, Michael Buesch wrote: > > > Well, it's not that easy. Current code just doesn't make any sense. > > I do not understand how hardware power control works exactly, so I > > can't write some detailed message or something. > > That's probably a chicken and egg problem ;) > > OK, the existing code complains that one number is larger than another. > You don't want to hide that message, but when I ask you to explain, you > say that the code makes no sense to you.
I will attempt an explanation of the issue, since I've been trying to wrap my own head around it lately. It boils down to a contradiction in the specs. For a G phy, the power control is set by 2 attenuation values. The chip wants the values themselves, and also the results of looking up these values in the LO table (which we build at device init and periodically refresh). The specs tell us how to build the LO table by looping over a list of values and measuring hardware parameters for each (http://bcm-v4.sipsolutions.net/802.11/LO/GPHY/BuildingTheTable). The list of values is supplied (http://bcm-v4.sipsolutions.net/802.11/LO/Tables). We make the LO lookup table large enough to hold all these values, but no larger than that (since anything else should not be initialized according to specs). Then the specs tell us to initialize the power control by setting the TX power variables to a known state and measuring power output (http://bcm-v4.sipsolutions.net/802.11/PHY/G/Power_Control). Here is the problem: One of the TX power values the spec tells us to use for this is larger than the max value used when building the LO lookup table. To set the TX power, we need to index into the LO table with these values. The spec is telling us to lookup an invalid index in the LO table. Currently, the driver deals with this by catching invalid LO table indexes and returning the value at the zero index. But this cannot possibly be the right thing to do; it merely avoids an oops in the driver. When high-level code tells low-level code to do something stupid, printing a warning seems appropriate (even if a stack trace is not needed any more). -- Will Dyson _______________________________________________ Bcm43xx-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
