Re: ath5k gets lost with eeepc-laptop removal
- From: "Nick Kossifidis" <mickflemm@xxxxxxxxx>
- Date: Fri, 31 Oct 2008 20:35:47 +0200
2008/10/31 Matthew Garrett <mjg59@xxxxxxxxxxxxx>:
On Fri, Oct 31, 2008 at 01:51:49PM +0000, Alan Jenkins wrote:
Matthew: I nagged you twice about different consequences of this
commit, so here's a third :). You said rfkill no longer automatically
frobs on suspend/resume, which was what I was worried about last time.
Should the core code also be modified so it doesn't do anything when
the rfkill device is unregistered?
I think there's definitely an argument in favour of that, though I
suspect that's a design feature - if you remove the control mechanism
for a radio, the safe state for that radio to be in is not transmitting.
It doesn't leave the radio in a state that's not transmitting, it
leaves the card in a state that doesn't get any power at all. I don't
see any reason for this, how do you define "safe" ?
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- References:
- ath5k gets lost with eeepc-laptop removal
- From: Luiz Fernando N. Capitulino
- Re: ath5k gets lost with eeepc-laptop removal
- From: Alan Jenkins
- Re: ath5k gets lost with eeepc-laptop removal
- From: Matthew Garrett
- ath5k gets lost with eeepc-laptop removal
- Prev by Date: Re: ath5k gets lost with eeepc-laptop removal
- Next by Date: Re: 2.6.28-rc1: NVRAM being corrupted on ppc64 preventing boot (bisected)
- Previous by thread: Re: ath5k gets lost with eeepc-laptop removal
- Next by thread: Re: ath5k gets lost with eeepc-laptop removal
- Index(es):
Relevant Pages
|