eeepc-laptop rfkill, stupid question #4 and 5 - Kernel

This is a discussion on eeepc-laptop rfkill, stupid question #4 and 5 - Kernel ; 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 ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 24

Thread: eeepc-laptop rfkill, stupid question #4 and 5

  1. eeepc-laptop rfkill, stupid question #4 and 5

    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
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: eeepc-laptop rfkill, stupid question #4 and 5

    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 | mjg59@srcf.ucam.org
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: eeepc-laptop rfkill, stupid question #4 and 5

    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
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: eeepc-laptop rfkill, stupid question #4 and 5

    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
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. Re: eeepc-laptop rfkill, stupid question #4 and 5

    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
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  6. Re: eeepc-laptop rfkill, stupid question #4 and 5

    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
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  7. Re: eeepc-laptop rfkill, stupid question #4 and 5

    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 | mjg59@srcf.ucam.org
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  8. Re: eeepc-laptop rfkill, stupid question #4

    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
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  9. Re: eeepc-laptop rfkill, stupid question #4

    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 | mjg59@srcf.ucam.org
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  10. Re: eeepc-laptop rfkill, stupid question #4

    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
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  11. Re: eeepc-laptop rfkill, stupid question #4

    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 | mjg59@srcf.ucam.org
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  12. Re: eeepc-laptop rfkill, stupid question #4

    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
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  13. Re: eeepc-laptop rfkill, stupid question #4

    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 | mjg59@srcf.ucam.org
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  14. Re: eeepc-laptop rfkill, stupid question #4

    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
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  15. Re: eeepc-laptop rfkill, stupid question #4

    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
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  16. Re: eeepc-laptop rfkill, stupid question #4

    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 | mjg59@srcf.ucam.org
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  17. Re: eeepc-laptop rfkill, stupid question #4

    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
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  18. Re: eeepc-laptop rfkill, stupid question #4

    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
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  19. Re: eeepc-laptop rfkill, stupid question #4

    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 | mjg59@srcf.ucam.org
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  20. Re: eeepc-laptop rfkill, stupid question #4

    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
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread
Page 1 of 2 1 2 LastLast