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

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

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 24 of 24

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

  1. Re: rfkill, stupid question #6

    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
    --
    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: rfkill, stupid question #6

    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
    --
    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

    Em Mon, 3 Nov 2008 14:33:11 -0200
    Henrique de Moraes Holschuh 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
    --
    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

    Luiz Fernando N. Capitulino wrote:
    > Em Mon, 3 Nov 2008 14:33:11 -0200
    > Henrique de Moraes Holschuh 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
    >



    --
    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 2 of 2 FirstFirst 1 2