Did you miss a call to rfkill_force_state() on resume?
I can hibernate, then interrupt the boot with F2 to get into the BIOS,
change the "Enable WLAN" setting, and continue the resume. When the
eeepc-laptop driver resumes, it restores the pre-hibernation value.
Actually, normal boot doesn't preserve the setting either. Your commit
changes the behaviour from the rfkill state being persistent across
reboot / power off (as a bios setting), to being always enabled on
boot. It seems like a bad idea to me.
Thanks
Alan
On Fri, Oct 31, 2008 at 05:09:09PM +0000, Alan Jenkins wrote:
> Did you miss a call to rfkill_force_state() on resume?
Conceivably. I didn't test the hibernation case.
> Actually, normal boot doesn't preserve the setting either. Your commit
> changes the behaviour from the rfkill state being persistent across
> reboot / power off (as a bios setting), to being always enabled on
> boot. It seems like a bad idea to me.
This is the behaviour of the rfkill core.
--
Matthew Garrett | [email protected]
Matthew Garrett wrote:
> On Fri, Oct 31, 2008 at 05:09:09PM +0000, Alan Jenkins wrote:
>
>> Did you miss a call to rfkill_force_state() on resume?
>>
>
> Conceivably. I didn't test the hibernation case.
>
>
>> Actually, normal boot doesn't preserve the setting either. Your commit
>> changes the behaviour from the rfkill state being persistent across
>> reboot / power off (as a bios setting), to being always enabled on
>> boot. It seems like a bad idea to me.
>>
>
> This is the behaviour of the rfkill core.
>
Documentation/rfkill.txt implied otherwise
You should:
- rfkill_allocate()
- modify rfkill fields (flags, name)
- modify state to the current hardware state (THIS IS THE ONLY TIME
YOU CAN ACCESS state DIRECTLY)
- rfkill_register()
Admittedly it doesn't say "and I promise not to gratuitously override
the state on registration". Buti t seems weird though, to override the
value on registration instead of just setting a default in
rfkill_allocate().
Thanks
Alan
Alan Jenkins wrote:
> Matthew Garrett wrote:
>
>> On Fri, Oct 31, 2008 at 05:09:09PM +0000, Alan Jenkins wrote:
>>
>>
>>> Did you miss a call to rfkill_force_state() on resume?
>>>
>>>
>> Conceivably. I didn't test the hibernation case.
>>
>>
>>
>>> Actually, normal boot doesn't preserve the setting either. Your commit
>>> changes the behaviour from the rfkill state being persistent across
>>> reboot / power off (as a bios setting), to being always enabled on
>>> boot. It seems like a bad idea to me.
>>>
>>>
>> This is the behaviour of the rfkill core.
>>
>>
> Documentation/rfkill.txt implied otherwise
>
> You should:
> - rfkill_allocate()
> - modify rfkill fields (flags, name)
> - modify state to the current hardware state (THIS IS THE ONLY TIME
> YOU CAN ACCESS state DIRECTLY)
> - rfkill_register()
>
>
> Admittedly it doesn't say "and I promise not to gratuitously override
> the state on registration". Buti t seems weird though, to override the
> value on registration
Ah, I see. Wrong end - of course the *rfkill device* doesn't have
useful state. The persistent state belongs to the *rfkill switch* - it
could even be a physical switch.
And now it's clear what was missing from the conversion to rfkill:
2. Input device switches (sources of EV_SW events) DO store their
current state
(so you *must* initialize it by issuing a gratuitous input layer
event on
driver start-up and also when resuming from sleep)
Regards
Alan
On Fri, 31 Oct 2008, Matthew Garrett wrote:
> > Actually, normal boot doesn't preserve the setting either. Your commit
> > changes the behaviour from the rfkill state being persistent across
> > reboot / power off (as a bios setting), to being always enabled on
> > boot. It seems like a bad idea to me.
>
> This is the behaviour of the rfkill core.
When you don't use rfkill_set_default(). Which, if you are a platform
driver, and your platform can store state across power off, you should use.
Yeah, it is a new thing, sort of. But it is in mainline already, so feel
free to use it. The right way to do it is to call it BEFORE doing any
rfkill_register or rfkill_allocate. Only the first caller for a given
rfkill type, wins.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
On Fri, 31 Oct 2008, Alan Jenkins wrote:
> > Documentation/rfkill.txt implied otherwise
Then we need to make it more clear.
> > You should:
> > - rfkill_allocate()
> > - modify rfkill fields (flags, name)
> > - modify state to the current hardware state (THIS IS THE ONLY TIME
> > YOU CAN ACCESS state DIRECTLY)
> > - rfkill_register()
At which point rfkill core will KICK your device to the state it wants it to
be, so if you lied on the state, you are screwed. I mean it.
You want rfkill_set_default(), and only because it is a platform driver
storing state across shutdown.
> > Admittedly it doesn't say "and I promise not to gratuitously override
> > the state on registration". Buti t seems weird though, to override the
> > value on registration
No, it is EXACTLY what it should do. It is setting policy for a class of
switches (actually, controllers. Call it a switch and you confuse it with
input devices). It is not "enabling the radio" by default, it is setting
the radio rfkill controllers to the same state that all other rfkill
controllers on radios of that type currently are at.
And there is rfkill_set_default() for *platform* drivers to influence that,
when the platform has a better idea of the proper initial radio rfkill
state.
> Ah, I see. Wrong end - of course the *rfkill device* doesn't have
> useful state. The persistent state belongs to the *rfkill switch* - it
> could even be a physical switch.
Of course it has useful state. Set it to whatever the rfkill controller
state really IS at that point. And it HAS persistent state, but the core
will govern it to match the system-wide policy.
> And now it's clear what was missing from the conversion to rfkill:
>
> 2. Input device switches (sources of EV_SW events) DO store their
> current state
> (so you *must* initialize it by issuing a gratuitous input layer
> event on
> driver start-up and also when resuming from sleep)
No.
You *ARE* to send gratuitous input layer events for SWITCHES quite often,
e.g. on every call to the switche's connect() handler, and also often after
system-wide stuff like resume (when state could have changed without you
being able to notice it) because you *HAVE* to tell the input layer which is
the initial/real state of the switch. If this is not clear, the input layer
needs some doc tweaking. Please feel free to send a patch to Dmitry.
But that has nothing to do with the rfkill core. You MUST NEVER try to
change rfkill core state through the input layer from inside the kernel.
NEVER.
rfkill_input is NOT part of the rfkill core, and rfkill_input is the ONLY
thing that cares about input events that match one of the "rfkill" input
events. And it *is* optional.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
On Sun, Nov 02, 2008 at 01:46:20AM -0200, Henrique de Moraes Holschuh wrote:
> When you don't use rfkill_set_default(). Which, if you are a platform
> driver, and your platform can store state across power off, you should use.
Ah, missed that. Yes, I'll fix that up.
--
Matthew Garrett | [email protected]
Henrique de Moraes Holschuh wrote:
> On Fri, 31 Oct 2008, Alan Jenkins wrote:
>
>>> Documentation/rfkill.txt implied otherwise
>>>
>
> Then we need to make it more clear.
>
>
>>> You should:
>>> - rfkill_allocate()
>>> - modify rfkill fields (flags, name)
>>> - modify state to the current hardware state (THIS IS THE ONLY TIME
>>> YOU CAN ACCESS state DIRECTLY)
>>> - rfkill_register()
>>>
>
> At which point rfkill core will KICK your device to the state it wants it to
> be, so if you lied on the state, you are screwed. I mean it.
>
> You want rfkill_set_default(), and only because it is a platform driver
> storing state across shutdown.
>
>
>>> Admittedly it doesn't say "and I promise not to gratuitously override
>>> the state on registration". Buti t seems weird though, to override the
>>> value on registration
>>>
>
> No, it is EXACTLY what it should do. It is setting policy for a class of
> switches (actually, controllers. Call it a switch and you confuse it with
> input devices). It is not "enabling the radio" by default, it is setting
> the radio rfkill controllers to the same state that all other rfkill
> controllers on radios of that type currently are at.
>
> And there is rfkill_set_default() for *platform* drivers to influence that,
> when the platform has a better idea of the proper initial radio rfkill
> state.
>
>
>> Ah, I see. Wrong end - of course the *rfkill device* doesn't have
>> useful state. The persistent state belongs to the *rfkill switch* - it
>> could even be a physical switch.
>>
>
> Of course it has useful state. Set it to whatever the rfkill controller
> state really IS at that point. And it HAS persistent state, but the core
> will govern it to match the system-wide policy.
>
>
>> And now it's clear what was missing from the conversion to rfkill:
>>
>> 2. Input device switches (sources of EV_SW events) DO store their
>> current state
>> (so you *must* initialize it by issuing a gratuitous input layer
>> event on
>> driver start-up and also when resuming from sleep)
>>
>
> No.
>
> You *ARE* to send gratuitous input layer events for SWITCHES quite often,
> e.g. on every call to the switche's connect() handler, and also often after
> system-wide stuff like resume (when state could have changed without you
> being able to notice it) because you *HAVE* to tell the input layer which is
> the initial/real state of the switch. If this is not clear, the input layer
> needs some doc tweaking. Please feel free to send a patch to Dmitry.
>
> But that has nothing to do with the rfkill core. You MUST NEVER try to
> change rfkill core state through the input layer from inside the kernel.
> NEVER.
>
> rfkill_input is NOT part of the rfkill core, and rfkill_input is the ONLY
> thing that cares about input events that match one of the "rfkill" input
> events. And it *is* optional.
>
Thanks for beating the clue into me. Part of the problem was I thought
the "toggle wireless" key on my keyboard somehow counted as a "switch"
input - but it doesn't, it's clearly just a normal "button" input.
Did you have any thoughts on the hibernation case? It's possible for the
rfkill state to change while hibernated. You can boot into a different
OS, or change it in the BIOS setup screen. At present the rfkill core
overrides the change on resume.
Personally I don't care. Hibernation plus dual-boot or BIOS setup can
already break in lots of exciting ways.
But I wonder if there are laptops where the BIOS handles rfkill by
default, but the OS takes over on boot. Thinkpads? Then you could toggle
the rfkill without going into the BIOS setup screen.
Actually, I think you could also do it if the resume kernel loads e.g.
eeepc-laptop before it loads the hibernation image. That's the strongest
argument I can think of.
Thanks
Alan
On Sun, Nov 02, 2008 at 11:17:34AM +0000, Alan Jenkins wrote:
> Did you have any thoughts on the hibernation case? It's possible for the
> rfkill state to change while hibernated. You can boot into a different
> OS, or change it in the BIOS setup screen. At present the rfkill core
> overrides the change on resume.
There are two choices. We can either set the rfkill to the hardware
state, or we can set the hardware state to the rfkill state. I think
both are valid choices and I'm happy to implement either of them in the
resume path. However, as you point out, right now it's possible for the
user to change the hardware state in the BIOS and cause the two to get
out of sync. That's certainly not ideal.
--
Matthew Garrett | [email protected]
Matthew Garrett wrote:
> On Sun, Nov 02, 2008 at 11:17:34AM +0000, Alan Jenkins wrote:
>
>
>> Did you have any thoughts on the hibernation case? It's possible for the
>> rfkill state to change while hibernated. You can boot into a different
>> OS, or change it in the BIOS setup screen. At present the rfkill core
>> overrides the change on resume.
>>
>
> There are two choices. We can either set the rfkill to the hardware
> state, or we can set the hardware state to the rfkill state. I think
> both are valid choices and I'm happy to implement either of them in the
> resume path. However, as you point out, right now it's possible for the
> user to change the hardware state in the BIOS and cause the two to get
> out of sync. That's certainly not ideal.
>
No, the current rfkill core forces the device to restore the state on
resume. So it can't be of sync after resume. And there's no way for
the platform driver to affect this behaviour, aside from illegally
generating input events.
If we want resume from hibernation to preserve the hardware state
instead of overriding it, the rfkill API needs changing. I'm not sure
how that can be justified, given how obscure it is as a use-case, and
the damage it would do to an API which already, uh, seems to be
frequently misunderstood.
Regards
Alan
On Sun, Nov 02, 2008 at 01:25:07PM +0000, Alan Jenkins wrote:
> No, the current rfkill core forces the device to restore the state on
> resume. So it can't be of sync after resume. And there's no way for
> the platform driver to affect this behaviour, aside from illegally
> generating input events.
Oh, so it does. Yeah, in that case I don't see any real point in
changing it.
--
Matthew Garrett | [email protected]
On Sun, 02 Nov 2008, Matthew Garrett wrote:
> resume path. However, as you point out, right now it's possible for the
> user to change the hardware state in the BIOS and cause the two to get
> out of sync. That's certainly not ideal.
In fact, it is a bug.
Can you read the state? If so, you need to unconditionally do so on resume
(from sleep or hibernation) and rfkill_force_state() it.
If you CANNOT read the state, you will have to force the radio to a known
state somehow.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
On Mon, Nov 03, 2008 at 12:16:28PM -0200, Henrique de Moraes Holschuh wrote:
> Can you read the state? If so, you need to unconditionally do so on resume
> (from sleep or hibernation) and rfkill_force_state() it.
The rfkill core actually forces the state on resume, so I think we're
fine.
--
Matthew Garrett | [email protected]
Matthew Garrett wrote:
> On Mon, Nov 03, 2008 at 12:16:28PM -0200, Henrique de Moraes Holschuh wrote:
>
>
>> Can you read the state? If so, you need to unconditionally do so on resume
>> (from sleep or hibernation) and rfkill_force_state() it.
>>
>
> The rfkill core actually forces the state on resume, so I think we're
> fine.
>
I think the reason it works is because eeepc-laptop provides a
"get_state" callback. rfkill can call get_state on resume, and if the
state has changed, force it back to the old value. So I think it's ok
as is.
Alan
On Sun, 02 Nov 2008, Alan Jenkins wrote:
> No, the current rfkill core forces the device to restore the state on
> resume. So it can't be of sync after resume. And there's no way for
> the platform driver to affect this behaviour, aside from illegally
> generating input events.
Actually, there might be some sort of mess in this (i.e. a bug in the core).
Here's what it is doing:
At resume, it does a forced rfkill_toggle_radio() with either the value
cached in rfkill->state or SOFT_BLOCK (if EPO is active), so
rfkill_toggle_radio() will call your driver's toggle_radio() hook regardless
of whether it thinks the rfkill state is already correct or not.
HOWEVER, rfkill->state *IS* updated by rfkill_force_state(), which your
driver is supposed to have called in its resume handling, that runs BEFORE
rfkill core's rfkill class resume hander (devices resume before their
classes AFAIK).
So, the core will NOT restore the pre-sleep state of the transmitter. It
will sync itself, and not cause worse trouble, but it seems not to be doing
what it is supposed to.
Argh.
I will send a patch after I do some testing to validate the above (and if
the bug is validated, after making sure the patch fixes it).
> If we want resume from hibernation to preserve the hardware state
> instead of overriding it, the rfkill API needs changing. I'm not sure
Oh, we DO want to override UNLESS what changed was actually something
capable of HARD_BLOCK (in which case the core already does things right if
you used rfkill_force_state()). It is the path of least surprise for the
user.
Frankly, I do not *CARE* to think about things like hibernate, boot another
OS, hibernate again or shutdown, try to boot back on the previous OS. This
is in NO WAY supported by ACPI, and can cause massive crappage if either OS
uses S4 instead of S5 for hibernation (and you ARE supposed to use S4, so
you can see the big pitfall right away).
All that matters is straight sleep-resume, hibernate-resume, and the fact
that the user IS allowed to mess with the hardware config (e.g. eject bays,
undock, remove non-fixed storage, and of course, toggle a hardware rfkill
input device).
> the damage it would do to an API which already, uh, seems to be
> frequently misunderstood.
That is an understatement... Hell, I probably am the one more acquinted
with the current rfkill API, and I still end up getting confused by it...
It really could benefit of a fine comb and code flow diagram analysis to
validate everything and catch bugs like the one I described above (which
*seems* to exist, I haven't tested for it yet, and I might be mistaken).
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
On Mon, 03 Nov 2008, Alan Jenkins wrote:
> >> Can you read the state? If so, you need to unconditionally do so on resume
> >> (from sleep or hibernation) and rfkill_force_state() it.
> >
> > The rfkill core actually forces the state on resume, so I think we're
> > fine.
Not if you can enter or exit HARD_BLOCK, you're not. If you cannot it is
fine. But if you can, you really need to rfkill_force_state() on resume,
even if you have a get_state() hook.
This might be something that needs explicit documentation, or something
wanting a fix.
> I think the reason it works is because eeepc-laptop provides a
> "get_state" callback. rfkill can call get_state on resume, and if the
It doesn't call get_state on resume right now, because rfkill_toggle_radio()
optimizes that away when called in forced mode.
I will think about removing that "optimization".
> state has changed, force it back to the old value. So I think it's ok
> as is.
And the rfkill core seems to be buggy when you call force_state() on resume,
which you guys didn't hit because you're not doing it yet. See my other
email...
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
On Mon, Nov 03, 2008 at 12:51:45PM -0200, Henrique de Moraes Holschuh wrote:
> Not if you can enter or exit HARD_BLOCK, you're not. If you cannot it is
> fine. But if you can, you really need to rfkill_force_state() on resume,
The state can always be overridden by software, so I think we're fine
there.
> And the rfkill core seems to be buggy when you call force_state() on resume,
> which you guys didn't hit because you're not doing it yet. See my other
> email...
Just to make sure: in the case where we *don't* support hard blocking,
there's no need to do anything special in the driver on resume and
rfkill should (but currently doesn't) do the right thing itself?
--
Matthew Garrett | [email protected]
On Mon, 03 Nov 2008, Matthew Garrett wrote:
> On Mon, Nov 03, 2008 at 12:51:45PM -0200, Henrique de Moraes Holschuh wrote:
> > Not if you can enter or exit HARD_BLOCK, you're not. If you cannot it is
> > fine. But if you can, you really need to rfkill_force_state() on resume,
>
> The state can always be overridden by software, so I think we're fine
> there.
The only things that can go out of HARD_BLOCK are rfkill_force_state() or a
call to get_state(), which will only happen much later (not during the
resume process).
> > And the rfkill core seems to be buggy when you call force_state() on resume,
> > which you guys didn't hit because you're not doing it yet. See my other
> > email...
>
> Just to make sure: in the case where we *don't* support hard blocking,
> there's no need to do anything special in the driver on resume and
> rfkill should (but currently doesn't) do the right thing itself?
Right now, you should still rfkill_force_state(). Please wait for an hour
or two while I clean up that broken resume handling, and I will tell you for
sure.
Chances are I can "un-optimize" rfkill_toggle_radio to always use
get_state(), and then your answer will be "yes, you don't need to
rfkill_force_state() ever if you don't support HARD_BLOCK".
Note that only using get_state() is NOT good for the user interface if the
firmware or hardware can change the rfkill state of the device.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
On Mon, Nov 03, 2008 at 01:02:29PM -0200, Henrique de Moraes Holschuh wrote:
> Right now, you should still rfkill_force_state(). Please wait for an hour
> or two while I clean up that broken resume handling, and I will tell you for
> sure.
Cool. I'll hold off posting my cleanups until then in that case.
--
Matthew Garrett | [email protected]
On Mon, 03 Nov 2008, Matthew Garrett wrote:
> On Mon, Nov 03, 2008 at 01:02:29PM -0200, Henrique de Moraes Holschuh wrote:
> > Right now, you should still rfkill_force_state(). Please wait for an hour
> > or two while I clean up that broken resume handling, and I will tell you for
> > sure.
>
> Cool. I'll hold off posting my cleanups until then in that case.
Ok, two bugs reproduced, the fixes are ready and tested, and I will be
sending it now to linux-wireless. You're in the CC, so you will get them.
I will also need to send patches for -stable, as the ones for mainline won't
apply to -stable.
Now, for what you asked: you DO NOT HAVE to use rfkill_force_state() in your
driver's resume method, as long as you NEVER make use of
RFKILL_STATE_HARD_BLOCKED. I have fixed the bug that was messing this up.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Henrique de Moraes Holschuh wrote:
> On Mon, 03 Nov 2008, Matthew Garrett wrote:
>
>> On Mon, Nov 03, 2008 at 01:02:29PM -0200, Henrique de Moraes Holschuh wrote:
>>
>>> Right now, you should still rfkill_force_state(). Please wait for an hour
>>> or two while I clean up that broken resume handling, and I will tell you for
>>> sure.
>>>
>> Cool. I'll hold off posting my cleanups until then in that case.
>>
>
> Ok, two bugs reproduced, the fixes are ready and tested, and I will be
> sending it now to linux-wireless. You're in the CC, so you will get them.
>
> I will also need to send patches for -stable, as the ones for mainline won't
> apply to -stable.
>
> Now, for what you asked: you DO NOT HAVE to use rfkill_force_state() in your
> driver's resume method, as long as you NEVER make use of
> RFKILL_STATE_HARD_BLOCKED. I have fixed the bug that was messing this up.
>
Thanks for fixing this, even though it doesn't affect my
non-STATE_HARD_BLOCKED-using hardware.
I have one more question. I read that if a STATE_SOFT_BLOCKED request
is made when the hardware is in STATE_HARD_BLOCKED, the rfkill driver is
expected to "double block".
If the hard block is later cleared, the driver is expected to call
rfkill_force_state(SOFT_BLOCKED). The SOFT_BLOCKED state can then be
cleared as normal.
But if there is an UNBLOCK request in the double-blocked state, the
rfkill core will reject it and preserve the double-blocked state. Is
this intended, or a known issue?
Wouldn't it be simpler to use a bitmask so that the rfkill core can at
least represent this double-blocked state? I guess the problem would be
how to shoehorn it into the sysfs interface.
Thanks
Alan
On Mon, 03 Nov 2008, Alan Jenkins wrote:
> I have one more question. I read that if a STATE_SOFT_BLOCKED request
> is made when the hardware is in STATE_HARD_BLOCKED, the rfkill driver is
> expected to "double block".
If it can do so, yes. It makes for marginally better use interaction.
> If the hard block is later cleared, the driver is expected to call
> rfkill_force_state(SOFT_BLOCKED). The SOFT_BLOCKED state can then be
> cleared as normal.
Exactly.
> But if there is an UNBLOCK request in the double-blocked state, the
> rfkill core will reject it and preserve the double-blocked state. Is
> this intended, or a known issue?
It is intended. The user wants to unblock the radio (not "prepare it to
unblock when I release the hardware rfkill line by doing something else"),
so we have to error it out.
And, frankly, I don't very much like the idea of the core returning a
-EPERM and yet having done a call toggle_radio(UNBLOCK). Not to mention
it is yet another border condition for the hook API.
So, if something took the pains to cause a double block, we require
explicit unblocking AFTER the hardware rfkill lines are released (i.e. the
device goes from HARD to SOFT blocked).
BUT I don't feel strongly about it, so if someone wants to change that, I
won't stand in the way.
> Wouldn't it be simpler to use a bitmask so that the rfkill core can at
> least represent this double-blocked state? I guess the problem would be
> how to shoehorn it into the sysfs interface.
The core doesn't care, and doesn't have to in order to implement such a
thing. The drivers track it separately.
The two problems is that it can be REALLY confusing for the end user, and
that it requires a ABI change. I don't know if it is worth it, I just know
I am not going to be the one doing it :-)
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Em Mon, 3 Nov 2008 14:33:11 -0200
Henrique de Moraes Holschuh <[email protected]> escreveu:
| On Mon, 03 Nov 2008, Matthew Garrett wrote:
| > On Mon, Nov 03, 2008 at 01:02:29PM -0200, Henrique de Moraes Holschuh wrote:
| > > Right now, you should still rfkill_force_state(). Please wait for an hour
| > > or two while I clean up that broken resume handling, and I will tell you for
| > > sure.
| >
| > Cool. I'll hold off posting my cleanups until then in that case.
|
| Ok, two bugs reproduced, the fixes are ready and tested, and I will be
| sending it now to linux-wireless. You're in the CC, so you will get them.
|
| I will also need to send patches for -stable, as the ones for mainline won't
| apply to -stable.
Great.
Do the patches have anything to do with the problem I have reported?
Rafael has opened a bugzilla ticket for it:
http://bugzilla.kernel.org/show_bug.cgi?id=11928
--
Luiz Fernando N. Capitulino
Luiz Fernando N. Capitulino wrote:
> Em Mon, 3 Nov 2008 14:33:11 -0200
> Henrique de Moraes Holschuh <[email protected]> escreveu:
>
> | On Mon, 03 Nov 2008, Matthew Garrett wrote:
> | > On Mon, Nov 03, 2008 at 01:02:29PM -0200, Henrique de Moraes Holschuh wrote:
> | > > Right now, you should still rfkill_force_state(). Please wait for an hour
> | > > or two while I clean up that broken resume handling, and I will tell you for
> | > > sure.
> | >
> | > Cool. I'll hold off posting my cleanups until then in that case.
> |
> | Ok, two bugs reproduced, the fixes are ready and tested, and I will be
> | sending it now to linux-wireless. You're in the CC, so you will get them.
> |
> | I will also need to send patches for -stable, as the ones for mainline won't
> | apply to -stable.
>
> Great.
>
> Do the patches have anything to do with the problem I have reported?
>
No. These patches don't affect what happens when the rfkill device is
unregistered.
> Rafael has opened a bugzilla ticket for it:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=11928
>