Oops, I got those parenthesis mixed up. You are right. My bad. But is AR9100 really not AR5416 based? For instance the devid define is named AR5416_AR9100_DEVID and the original firmware reports the chipset as ath_hal: 0.9.17.1 (AR5416, DEBUG, REGOPS_FUNC, WRITE_EEPROM, 11D) Confusing, but you are probably right. /Björn 2010/2/27 Felix Fietkau <nbd@xxxxxxxxxxx>: > On 2010-02-27 6:26 PM, Björn Smedman wrote: >> The AR_SREV_5416() macro evaluates to false for AR9100 while the >> definitions for AR_SREV_5416_20_OR_LATER() and >> AR_SREV_5416_22_OR_LATER() seem to assume AR9100 based chips fall >> under this category. For example the last line of >> >> #define AR_SREV_5416_20_OR_LATER(_ah) \ >> (((AR_SREV_5416(_ah)) && \ >> ((_ah)->hw_version.macRev >= AR_SREV_REVISION_5416_20)) || \ >> ((_ah)->hw_version.macVersion >= AR_SREV_VERSION_9100)) >> >> makes no sense if AR_SREV_5416(_ah) is false when >> (_ah)->hw_version.macVersion == AR_SREV_VERSION_9100. > I think this is wrong. The AR_SREV_xxxx macros typically point to a > specific chip generation, whereas the AR_SREV_XXXX_OR_LATER() point to > the chip generation or any later. > AR9100 is related to AR9160, but not AR5416, so AR_SREV_5416() should > return false for 9100 based devices. > If you look at the AR_SREV_5416_20_OR_LATER macros, they do not assume > that AR_SREV_5416() evaluates to true for the > ((_ah)->hw_version.macVersion >= AR_SREV_VERSION_9100) case, as it's > either (is 5416 && macRev >= 20) or macVersion > 9100 > > - Felix > -- Venatech AB Ideon Innovation Ole Römers väg 12 SE-22370 LUND Sweden +46 (0) 46 286 86 20 info@xxxxxxxxxxx http://www.venatech.se -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
