IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Without this we have no gaurantee of the integrity of the
EEPROM and are likely to encounter a lot of bogus bug reports
due to actual issues on the EEPROM. With the EEPROM checksum
check in place we can easily rule those issues out.
If you run patch during a revert *you* have a card with a busted
EEPROM and only older kernel will support that concoction. This
patch is a trade off between not accepitng bogus EEPROMs and
avoiding bogus bug reports allowing developers to focus instead
on real concrete issues.
If stable keeps bogus bug reports because of a possibly busted EEPROM
feel free to apply this there too.
Tested on an AR5414
Cc: stable@kernel.org
Cc: jirislaby@gmail.com
Cc: akpm@linux-foundation.org
Cc: rjw@sisk.pl
Cc: me@bobcopeland.com
Cc: david.quan@atheros.com
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
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@gnu.org>
Acked-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
* Read PCI-E infos offset from EEPROM and if it points to
serdes section (0x40), enable serdes programming (further tweaking
of serdes values during attach). This follows Legacy and Sam's
HAL sources.
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Acked-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
* Add code to support the various antenna scenarios supported by hw
* For now hardcode the default scenario (single or dual omnis with
tx/rx diversity working and tx antenna handled by session -hw keeps
track on which antenna it got ack from each ap/station and maps each
ap/station to one of the antennas-).
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
* Put remaining EEPROM information on ee struct and remove is_hb63
function.
Now we also have rfkill stuff available.
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
* Read Spur channel information from EEPROM and use default channels
for RF5413 compatible chips that don't have this info on EEPROM.
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
commit 8e218fb24faef0bfe95bc91b3c05261e20439527 reverted the previous
patch (commit 925be8a3077351edbf2b59ca689105df214a0792).
The C99 specification states in section 6.11.5:
The placement of a storage-class specifier other than at the
beginning of the declaration specifiers in a declaration is an
obsolescent feature.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Acked-by: Jiri Slaby <jirislaby@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
