You could just look at the code in ath5k/rfkill.c and just comment out
the code that glues together the rfkill GPIO pin to the "rfkill"
personality.
(ie, GPIO pins have "personalities", they can be configured as input,
output, rfkill to the baseband, other stuff..)
If the pin isn't configured as having the "rfkill" personality and if
rfkill isn't configured in general, then the state of pin 13 shouldn't
matter..
adrian
On 4 August 2011 16:40, Antonis Tsolomitis <antonis.tsolomi...@gmail.com> wrote:
>
> I am sorry, I do not understand anything from the below technical message.
> Does this mean that the only solution is to cover pin13?
>
> Can't it be done with ath5k? It was working fine with ath_pci. So the
> code in ath_pci exists.
> It can't be so difficult to fix...
>
> Antonis.
>
>
> Στις 04/08/2011 01:58 πμ, ο/η Adrian Chadd έγραψε:
>>> Obviously, something is wrong with ath5k. If the device is "hard
>>> blocked", how come it can be enabled by disabling "rfkill"? We need to
>>> change the logic here. If the pin 13 can be overridden, it should be
>>> treated like an input device, not as a hardware block.
>> It looks like you can disable the GPIO "personality" by disabling that
>> its wired to the baseband "rfkill".
>>
>> ath5k seems to let you program the GPIO pin value and have that
>> control rfkill in software.
>>
>> I haven't tried that though. The point is, the GPIO pin is configured
>> as an input to rfkill, rather than a generic input pin.
>>
>> The reference driver doesn't enable it for interrupts for all hardware:
>>
>> if (capability == 3) { /* rfkill interrupt */
>> return ((IS_5424(ah) || IS_2425(ah)) ?
>> HAL_ENOTSUPP : HAL_OK);
>> }
>>
>> .. looks like FreeBSD may need to be taught this too. I'll have to do
>> some digging to see why this is the case.
>>
>>
>>
>> Adrian
>
>
_______________________________________________
ath5k-devel mailing list
ath5k-devel@lists.ath5k.org
https://lists.ath5k.org/mailman/listinfo/ath5k-devel
