RE: [Madwifi-users] Laptop RfKill issue
Status: Beta
Brought to you by:
otaku
From: William S. K. <ws...@ya...> - 2003-09-28 22:14:43
|
Thanks. I'm still not exactly certain what conclusion to draw. Would = the current partial sw implemention of the rfkill functionality result in = the radio being enabled or disabled? Is there an easy way to tell if the = radio is enabled (hal dump?). -Bill -----Original Message----- From: mad...@li... [mailto:mad...@li...] On Behalf Of Sam = Leffler Sent: Sunday, September 28, 2003 12:01 PM To: ws...@ya...; mad...@li... Cc: 'Greg Chesson' Subject: Re: [Madwifi-users] Laptop RfKill issue > I'm trying to get a 5212-based minipci card working in a laptop=20 > (Chembook 3812/Compal CQ12) but I'm running into what looks like an=20 > 'rfkill' issue as the driver is operational but nothing is ever=20 > received and transmissions never actually appear 'on the wire'. =20 > Furthermore a call to the HAL RfKill reporting function is returning=20 > 'true' whereas on a normal system it returns 'false'. >=20 ah_getRfKill reports whether not the rfkill functionality is present and enabled in the EEPROM. As a side effect it also setups the GPIO = parameters needed for it to operate. This method is called during ah_reset to = decide if the GPIO should be setup to enable RFkill switch interrupts. It = probably doesn't even need to be exposed outside the HAL (I did it just in = case...). > Pressing the laptop pushbutton presumably associated with the rfkill=20 > signal state has no apparent effect. Is the mini-pci rfkill interface = > standardized? I've found web references to 'RF Silent' functionality=20 > being controlled by minipci pin #13 (active low). Would it be correct = > to assume the atheros card is doing the right thing wrt rfkill signal=20 > handling and that the problem is with the laptop's generation/toggling = > of the signal? Or maybe the interface isn't really standardized and=20 > the laptop and card have different ideas about rfkill? Any suggested=20 > workarounds? >=20 The HAL sets up the GPIO interrupt but doesn't enable the bit in the interrupt mask; the driver needs to do this when it's ready to handle = the interrupt. This support is not yet in the driver (Greg was talking = about doing it as he has a laptop with this feature). To understand what to = do with the interrupt I need to look at some other stuff (don't have time = right now). > In a previous message Greg mentioned that the signal comes onto the=20 > atheros GPIO pins. For the purpose of further investigation, what are=20 > the semantics of the HAL gpioGet function (i.e. what is its uint32 = arg)? Let me answer this with the above... Sam |