backport of commit
85efc86eb7c6cbb1c8ce8d99b10b948be033fbb9 upstream.
We fail if your EEPROM is busted but we were never propagated the
error back so such users could end up with a cryptic oops message
like:
IP: [<
f883e1b9>] ath9k_reg_apply_world_flags+0x29/0x130 [ath9k]
*pde =
00000000
Oops: 0000 [#1] SMP
Modules linked in: ath9k(+) mac80211 cfg80211
Pid: 4284, comm: insmod Not tainted (2.6.29-wl #3)
7660A14
EIP: 0060:[<
f883e1b9>] EFLAGS:
00010286 CPU: 1
EIP is at ath9k_reg_apply_world_flags+0x29/0x130 [ath9k]
Fix this by propagating the error and also lets not leave the
user in the dark and communicate what's going on. When this
happens you will now see this:
ath9k 0000:16:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
ath9k: Invalid EEPROM contents
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
for (i = 0; i < sc->keymax; i++)
ath9k_hw_keyreset(ah, (u16) i);
- if (ath9k_regd_init(sc->sc_ah))
+ error = ath9k_regd_init(sc->sc_ah);
+ if (error)
goto bad;
/* default to MONITOR mode */
u16 regdmn;
if (!ath9k_regd_is_eeprom_valid(ah)) {
- DPRINTF(ah->ah_sc, ATH_DBG_REGULATORY,
+ DPRINTF(ah->ah_sc, ATH_DBG_FATAL,
"Invalid EEPROM contents\n");
return -EINVAL;
}