On Wed, Feb 29, 2012 at 4:33 PM, Matt Chen <machen@xxxxxxxx> wrote: > Hi list, > > I am working on verifying the ath9k_rfkill_poll_state() function. It > would execute the ath_is_rfkill_set() the read the GPIO and change the > LED. I found the POLL_INTERVAL would take 5 secs according the > definition in net/rfkill/core.c > #define POLL_INTERVAL (5 * HZ) > So it would detect the GPIO status in every 5 seconds. But the ath9k I > run in different platform, with the same modules, it works different > way. The LED for one is working very fast, in another one is working > so slow. > > I would like to clarify it is driver or BIOS issues. The way I come > out is manually to change the GPIO status, see how the driver work. > But so far I only found the devmen2 to access the specific address of > GPIO. Any other good ways recommended ? > And another question is the address defined in reg.h correct to access > ? Such as > #define AR_GPIO_IN (AR_SERV_9340(ah)) ? 0x402c : 0x404c) > can I access the value of 0x404c directly? yes you can, one idea i have is to enable ath9k debug http://linuxwireless.org/en/users/Drivers/ath9k/debug and echo 0x404c in the regidx field in debug and keep looking for regval, in which the corresponding rfkill related bit may toggle, when the rfkill is enabled > > Thank you for your patience. :) > -- > 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 -- thanks, shafi -- 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
