[PATCH 0/1] toshiba_acpi: Add support for bluetooth toggling through rfkill - Kernel

This is a discussion on [PATCH 0/1] toshiba_acpi: Add support for bluetooth toggling through rfkill - Kernel ; As requested by Henrique, I have reworked this patch against wireless-testing and it uses the new-style rfkill API and to report the input device as a switch. I did some digging to try and find a usable gpe event but ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: [PATCH 0/1] toshiba_acpi: Add support for bluetooth toggling through rfkill

  1. [PATCH 0/1] toshiba_acpi: Add support for bluetooth toggling through rfkill

    As requested by Henrique, I have reworked this patch against wireless-testing
    and it uses the new-style rfkill API and to report the input device as a switch.

    I did some digging to try and find a usable gpe event but had only limited
    success. From another look through the AML, it uses GPE08 for almost everything
    - inspecting a bunch of state for each event and then sending notifications on
    different objects. I couldn't find one for the hardware kill switch itself but I
    did manage to find one that's emitted when the bluetooth device enters the
    equivalent of the SOFT_BLOCKED state. This is useful for noticing that the
    hardware switch has been released, but it also fires on transitions from UNBLOCKED
    to SOFT_BLOCKED - so I had to try and avoid turning around and unblocking the
    device! I'm not particularly happy with how I did it (ignore-the-next-event)
    but I can't think of a better way.

    --phil
    --
    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: [PATCH 0/1] toshiba_acpi: Add support for bluetooth toggling through rfkill

    On Sun, 27 Jul 2008, Philip Langdale wrote:
    > different objects. I couldn't find one for the hardware kill switch itself but I
    > did manage to find one that's emitted when the bluetooth device enters the
    > equivalent of the SOFT_BLOCKED state. This is useful for noticing that the
    > hardware switch has been released, but it also fires on transitions from UNBLOCKED
    > to SOFT_BLOCKED - so I had to try and avoid turning around and unblocking the
    > device! I'm not particularly happy with how I did it (ignore-the-next-event)
    > but I can't think of a better way.


    Can it be used as an event that you just take as a hint to READ the state
    of the switch? I.e. as "switch may have changed state, you better check"
    instead of "switch changed state"?

    --
    "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: [PATCH 0/1] toshiba_acpi: Add support for bluetooth toggling through rfkill (v2)

    Philip Langdale wrote:
    > As requested by Henrique, I have reworked this patch against
    > wireless-testing
    > and it uses the new-style rfkill API and to report the input device as a
    > switch.
    >
    > I did some digging to try and find a usable gpe event but had only limited
    > success. From another look through the AML, it uses GPE08 for almost
    > everything
    > - inspecting a bunch of state for each event and then sending
    > notifications on
    > different objects. I couldn't find one for the hardware kill switch
    > itself but I
    > did manage to find one that's emitted when the bluetooth device enters the
    > equivalent of the SOFT_BLOCKED state. This is useful for noticing that the
    > hardware switch has been released, but it also fires on transitions from
    > UNBLOCKED
    > to SOFT_BLOCKED - so I had to try and avoid turning around and
    > unblocking the
    > device! I'm not particularly happy with how I did it
    > (ignore-the-next-event)
    > but I can't think of a better way.


    I've updated the diff to use force_state instead of get_state. I'm a little
    unhappy in that it requires poking the rfkill state from the input poll
    function but that's the only way we know anything changed.

    The event handling is still the same as before because I realised that there's
    no fundamental state I can use to distinguish the two transitions - at the time
    the event fires, the kill switch is inactive and the bluetooth device is
    disconnected but we simply don't know where we came from (hard killed or on),
    so we have to maintain some form of state in the driver and the current mechanism
    is as good (or bad) as any other.

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