lkml.org 
[lkml]   [2017]   [Oct]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    From
    Date
    Subject[PATCH 3.16 155/192] Revert "ACPI / EC: Add support to disallow QR_EC to be issued before completing previous QR_EC"
    3.16.49-rc1 review patch.  If anyone has any objections, please let me know.

    ------------------

    From: Lv Zheng <lv.zheng@intel.com>

    commit df9ff91801da603079018f21a9412385b62f0f8e upstream.

    It is reported that the following commit breaks Samsung hardware:
    Commit: 558e4736f2e1b0e6323adf7a5e4df77ed6cfc1a4.
    Subject: ACPI / EC: Add support to disallow QR_EC to be issued before
    completing previous QR_EC

    Which means the Samsung behavior conflicts with the Acer behavior.

    1. Samsung may behave like:
    [ +event 1 ] SCI_EVT set
    [ +event 2 ] SCI_EVT set
    write QR_EC
    read event
    [ -event 1 ] SCI_EVT clear
    Without the above commit, Samsung can work:
    [ +event 1 ] SCI_EVT set
    [ +event 2 ] SCI_EVT set
    write QR_EC
    CAN prepare next QR_EC as SCI_EVT=1
    read event
    [ -event 1 ] SCI_EVT clear
    write QR_EC
    read event
    [ -event 2 ] SCI_EVT clear
    With the above commit, Samsung cannot work:
    [ +event 1 ] SCI_EVT set
    [ +event 2 ] SCI_EVT set
    write QR_EC
    read event
    [ -event 1 ] SCI_EVT clear
    CANNOT prepare next QR_EC as SCI_EVT=0
    2. Acer may behave like:
    [ +event 1 ] SCI_EVT set
    [ +event 2 ]
    write QR_EC
    read event
    [ -event 1 ] SCI_EVT clear
    [ +event 2 ] SCI_EVT set
    Without the above commit, Acer cannot work when there is only 1 event:
    [ +event 1 ] SCI_EVT set
    write QR_EC
    can prepared next QR_EC as SCI_EVT=1
    read event
    [ -event 1 ] SCI_EVT clear
    CANNOT write QR_EC as SCI_EVT=0
    With the above commit, Acer can work:
    [ +event 1 ] SCI_EVT set
    [ +event 2 ]
    write QR_EC
    read event
    [ -event 1 ] SCI_EVT set
    can prepare next QR_EC because SCI_EVT=0
    CAN write QR_EC as SCI_EVT=1

    Since Acer can also work with only the following commit applied:
    Commit: 3afcf2ece453e1a8c2c6de19cdf06da3772a1b08
    Subject: ACPI / EC: Add support to disallow QR_EC to be issued when
    SCI_EVT isn't set
    commit 558e4736f2e1b0e6323adf7a5e4df77ed6cfc1a4 can be reverted.

    Fixes: 558e4736f2e1 (ACPI / EC: Add support to disallow QR_EC to be issued ...)
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=44161
    Reported-and-tested-by: Ortwin Glück <odi@odi.ch>
    Signed-off-by: Lv Zheng <lv.zheng@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    [bwh: Backported to 3.16: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    ---
    drivers/acpi/ec.c | 6 +++---
    1 file changed, 3 insertions(+), 3 deletions(-)

    --- a/drivers/acpi/ec.c
    +++ b/drivers/acpi/ec.c
    @@ -299,11 +299,11 @@ static int acpi_ec_transaction_unlocked(
    /* following two actions should be kept atomic */
    ec->curr = t;
    start_transaction(ec);
    + if (ec->curr->command == ACPI_EC_COMMAND_QUERY)
    + clear_bit(EC_FLAGS_QUERY_PENDING, &ec->flags);
    spin_unlock_irqrestore(&ec->lock, tmp);
    ret = ec_poll(ec);
    spin_lock_irqsave(&ec->lock, tmp);
    - if (ec->curr->command == ACPI_EC_COMMAND_QUERY)
    - clear_bit(EC_FLAGS_QUERY_PENDING, &ec->flags);
    ec->curr = NULL;
    spin_unlock_irqrestore(&ec->lock, tmp);
    return ret;
    \
     
     \ /
      Last update: 2017-10-09 15:55    [W:4.260 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site