Re: [ath5k-devel] ath5k fails to activate card
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
Re: [ath5k-devel] ath5k fails to activate card
2011/8/4 Nick Kossifidis mickfl...@gmail.com: 2011/8/3 Pavel Roskin pro...@gnu.org: On 08/03/2011 08:42 AM, Antonis Tsolomitis wrote: Yes I have tried this. It still is hardware blocked: Antonis. # rfkill list 0: phy0: Wireless LAN Soft blocked: no Hard blocked: yes # rfkill unblock all # rfkill list 0: phy0: Wireless LAN Soft blocked: no Hard blocked: yes Actually, I have one card that works with rfkill disabled, but doesn't work with rfkill enabled. Just like your case, the device is hard blocked. It is a miniPCI card (Valemount KXS30SG) installed in a Mikrotik RB-14 adapter. The problem with that adapter is that it signals to the cards the WiFi should be disabled. This can be fixed by applying an isolating cover on the pin 13: https://madwifi-project.org/wiki/UserDocs/MiniPCI 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. They have probably connected the GPIO pins in a different way on the laptop's side so ath5k might think that LED pin is RFKIL and RFKIL is LED or something like that. Normaly the rfkill pin and polarity are stored on card's EEPROM but if you put your card on a laptop with different settings the card's vendor wouldn't know what to put there. We have something for LEDS already in led.c, we might have to introduce a similar table for RFKill. Or maybe a module parameter/debugfs entry to disable rfkill on devices with problems. Anyway the fast solution is just to skip RFKill check, go to drivers/net/wireless/ath/ath5k/rfkill.c and make ath5k_is_rfkill_set always return 0. If you have time to debug it check out the values for rfkill polarity and pin number and try tweaking them. Your laptop doesn't have a hw rfkill switch but it might have a bios one, normaly there should be an fn+some function key to enable/disable wifi, check it out. In some cases this might actually be a hw switch. BTW the above was a reply to Antonis :P -- GPG ID: 0xD21DB2DB As you read this post global entropy rises. Have Fun ;-) Nick ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] ath5k fails to activate card
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
