2009/8/27 Nick Kossifidis <mickflemm@xxxxxxxxx>: > 2009/8/27 Pavel Roskin <proski@xxxxxxx>: >> The `val' variable in ath5k_eeprom_read_turbo_modes() is used >> uninitialized. gcc 4.4.1 with -fno-inline-functions-called-once reports >> it: >> >> eeprom.c: In function 'ath5k_eeprom_read_turbo_modes': >> eeprom.c:441: warning: 'val' may be used uninitialized in this function >> >> Comparing the code to the Atheros HAL, it's clear that the split between >> ath5k_eeprom_read_modes() and ath5k_eeprom_read_turbo_modes() was >> incorrect. >> >> The Atheros HAL reads both turbo and non-turbo data from EEPROM in one >> function. Some turbo mode parameters are derived from the same EEPROM >> values as non-turbo parameters, just from different bits. >> >> Merge ath5k_eeprom_read_turbo_modes() into ath5k_eeprom_read_modes() to >> fix the warning. The actual values and offsets have been cross-checked >> against Atheros HAL. >> >> Signed-off-by: Pavel Roskin <proski@xxxxxxx> > > Current code works fine (i 've checked it against various cards), > there is nothing wrong > with having another function for reading turbo modes, i find it's > cleaner that way. > > Just change > > u16 val; > > to > > u16 val = 0; > > and it should be fine. > Ouch seems my local tree and current wireless-testing are out of sync or something, yup compiler is right you' ll need to put a AR5K_EEPROM_READ(o, val); before the switch. -- GPG ID: 0xD21DB2DB As you read this post global entropy rises. Have Fun ;-) Nick -- 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