When the EEPROM is not in good condition we cannot continue so
we currently bail out but only ath5k is bailing out properly.
Both ath9k and ar9170 were proceeding and if a user were to run
into this they'd see an obscure panic. Lets propagate the error
as intended and make sure we inform the user by lifting the
error message from debug to a kernel error.
Stable note: You can find a port of this page here:
http://bombadil.infradead.org/~mcgrof/patches/ath9k/ath9k-fix-eeprom.patch.txt
Cc: stable@kernel.org
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
err = ath_regd_init(&ar->regulatory, ar->hw->wiphy,
ar9170_reg_notifier);
+ if (err)
+ goto err_out;
err = ieee80211_register_hw(ar->hw);
if (err)
for (i = 0; i < sc->keymax; i++)
ath9k_hw_keyreset(ah, (u16) i);
- if (ath_regd_init(&sc->sc_ah->regulatory, sc->hw->wiphy,
- ath9k_reg_notifier))
+ error = ath_regd_init(&sc->sc_ah->regulatory, sc->hw->wiphy,
+ ath9k_reg_notifier);
+ if (error)
goto bad;
/* default to MONITOR mode */
u16 regdmn;
if (!ath_regd_is_eeprom_valid(reg)) {
- printk(KERN_DEBUG "ath: Invalid EEPROM contents\n");
+ printk(KERN_ERR "ath: Invalid EEPROM contents\n");
return -EINVAL;
}