hmm... that would mean i would have to add support for overlapping ranges to the script (searching for the most specific matching one) or add a special case for AR5K_PHY which i'm not quite ready to do for an idea i'm not 100% convinced of anyways. feel free to do it.
bruno On Wednesday 31 October 2007 10:01:47 Nick Kossifidis wrote: > I think it's more easy to remember an int (eg AR5K_PHY(231)) than a > hex value + it makes searching more easy (eg. we'll want to see when > and how often a register is written so we might figure out what it > is). > > We can limit this, the last known phy register is > AR5K_PHY_GAIN_2GHZ 0xa20c > > so we might declare any register above this as unknown and instead > print it's address. > > 2007/10/31, bruno randolf <[EMAIL PROTECTED]>: > > ok. i updated the values in the wiki. delete your ath_registers.wiki.txt > > and it will be fetched again. > > > > for AR5K_PHY (0x9800-???): do you really think it is a good idea? > > i think using symbolic names like AR5K_PHY(231) just hide away the fact > > that we don't know anything about it. i'd rather prefer to use the hex > > value to make that clear. > > > > bruno > > > > On Tuesday 30 October 2007 23:35:11 Nick Kossifidis wrote: > > > > sure, it's as easy as adding the right ranges to the wiki. > > > > can you tell me the end addresses? > > > > > > > > i'm guessing: > > > > > > > > 0x9a00-0x9aff ??? AR5K_RF_GAIN > > > > 0x9b00-0x9c00 ??? AR5K_BB_GAIN ??? > > > > > > RF_GAIN and BB_GAIN tables are 64bytes each > > > so its from AR5K_RF_GAIN(0) to AR5K_RF_GAIN(63) > > > (0x9a00 - 0x9afc) > > > and for BB_GAIN > > > (0x9b00 - 0x9bfc) > > > > > > > 0xa180-0x0a200 ??? AR5K_PHY_PCDAC_TXPOWER ??? > > > > > > this one is 32bytes so it's > > > (0xa180 - 0xa1fc) > > > > > > > 0x8700-0x8800 ??? AR5K_RATE_DUR ??? > > > > > > also 32bytes so it's > > > (0x8700 - 0x877c) > > > > > > > 0x9800- ??? AR5K_PHY > > > > > > This is indeed weird, it seems that any register from 9800+ is PHY > > > register so we want to display AR5K_PHY for them (those we don't know > > > about). > > > > > > > please confirm... > > > > > > > > another note: > > > > AR5K_KEYTABLE(index) is not handled right, it is treated like the > > > > other ranges with (index << 2). > > > > > > > > bruno > > > > > > We can skip that for the moment (it should be base + (index << 5)), > > > wep is confirmed to work for now, we need first to fix that b/g cards > > > bug and then phy initialization for 5424/2424 and rest single-chips. _______________________________________________ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
