Hi all, 2012/3/5 Matt Chen <machen@xxxxxxxx>: > Hi, > > 2012/3/1 Mohammed Shafi <shafi.wireless@xxxxxxxxx>: >> 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 > echo 0x404c to which file in /sys/kernel/debug/ath9k ? I think I got it. Thanks > Thanks >>> >>> 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
