Re: eeepc-laptop rfkill, stupid question #4

[Henrique de Moraes Holschuh <hmh@hmh.eng.br>]

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