2012.08.23. 11:28 keltezéssel, Simon Wunderlich írta: > Hello Adrian, > > thanks for your comments! > > On Wed, Aug 22, 2012 at 11:57:04AM -0700, Adrian Chadd wrote: >> Yeah. The deadbeef means "something's turned off." >> >> I'd start with the SoC reset register and see if the MAC/WMAC bits are >> correctly set. Ie, that something hasn't gone and reset the wireless >> bits behind your back. > > Sure, but which register would that be? How can I find out? Is it included > in regdump of ath9k debugfs? It is the AR933X_RESET_REG_RESET_MODULE register (0x1806001c), and the reset of the WMAC chip is controlled by the AR933X_RESET_WMAC bit. You can find the definitions in arch/mips/include/asm/mach-ath79/ar71xx_regs.h. The platform device registration code pulls the WMAC chip out of reset before registering the device. See the 'ar933x_wmac_setup' function in 'arch/mips/ath79/dev-wmac.c'. Then only the ath9k driver controls the hardware reset line indirectly via ah->external_reset. However, I doubt that the 0xdeadbeef values are caused by this. If the AR933X_RESET_WMAC bit is set in the reset register, the WMAC chip is not accessible at all. If the AR933X_RESET_WMAC bit is set and the driver tries to access the WMAC registers, the board locks up completely, or reboots itself. At least I have experienced this earlier. -Gabor -- 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
