1. 28 10月, 2016 1 次提交
  2. 21 10月, 2016 9 次提交
  3. 20 10月, 2016 21 次提交
  4. 19 10月, 2016 7 次提交
  5. 18 10月, 2016 2 次提交
    • M
      pinctrl: intel: Only restore pins that are used by the driver · c538b943
      Mika Westerberg 提交于
      Dell XPS 13 (and maybe some others) uses a GPIO (CPU_GP_1) during suspend
      to explicitly disable USB touchscreen interrupt. This is done to prevent
      situation where the lid is closed the touchscreen is left functional.
      
      The pinctrl driver (wrongly) assumes it owns all pins which are owned by
      host and not locked down. It is perfectly fine for BIOS to use those pins
      as it is also considered as host in this context.
      
      What happens is that when the lid of Dell XPS 13 is closed, the BIOS
      configures CPU_GP_1 low disabling the touchscreen interrupt. During resume
      we restore all host owned pins to the known state which includes CPU_GP_1
      and this overwrites what the BIOS has programmed there causing the
      touchscreen to fail as no interrupts are reaching the CPU anymore.
      
      Fix this by restoring only those pins we know are explicitly requested by
      the kernel one way or other.
      
      Cc: stable@vger.kernel.org
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=176361Reported-by: NAceLan Kao <acelan.kao@canonical.com>
      Tested-by: NAceLan Kao <acelan.kao@canonical.com>
      Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      c538b943
    • V
      pinctrl: baytrail: Fix lockdep · a171bc51
      Ville Syrjälä 提交于
      Initialize the spinlock before using it.
      
      INFO: trying to register non-static key.
      the code is fine but needs lockdep annotation.
      turning off the locking correctness validator.
      CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.8.0-dwc-bisect #4
      Hardware name: Intel Corp. VALLEYVIEW C0 PLATFORM/BYT-T FFD8, BIOS BLAKFF81.X64.0088.R10.1403240443 FFD8_X64_R_2014_13_1_00 03/24/2014
       0000000000000000 ffff8800788ff770 ffffffff8133d597 0000000000000000
       0000000000000000 ffff8800788ff7e0 ffffffff810cfb9e 0000000000000002
       ffff8800788ff7d0 ffffffff8205b600 0000000000000002 ffff8800788ff7f0
      Call Trace:
       [<ffffffff8133d597>] dump_stack+0x67/0x90
       [<ffffffff810cfb9e>] register_lock_class+0x52e/0x540
       [<ffffffff810d2081>] __lock_acquire+0x81/0x16b0
       [<ffffffff810cede1>] ? save_trace+0x41/0xd0
       [<ffffffff810d33b2>] ? __lock_acquire+0x13b2/0x16b0
       [<ffffffff810cf05a>] ? __lock_is_held+0x4a/0x70
       [<ffffffff810d3b1a>] lock_acquire+0xba/0x220
       [<ffffffff8136f1fe>] ? byt_gpio_get_direction+0x3e/0x80
       [<ffffffff81631567>] _raw_spin_lock_irqsave+0x47/0x60
       [<ffffffff8136f1fe>] ? byt_gpio_get_direction+0x3e/0x80
       [<ffffffff8136f1fe>] byt_gpio_get_direction+0x3e/0x80
       [<ffffffff813740a9>] gpiochip_add_data+0x319/0x7d0
       [<ffffffff81631723>] ? _raw_spin_unlock_irqrestore+0x43/0x70
       [<ffffffff8136fe3b>] byt_pinctrl_probe+0x2fb/0x620
       [<ffffffff8142fb0c>] platform_drv_probe+0x3c/0xa0
      ...
      
      Based on the diff it looks like the problem was introduced in
      commit 71e6ca61 ("pinctrl: baytrail: Register pin control handling")
      but I wasn't able to verify that empirically as the parent commit
      just oopsed when I tried to boot it.
      
      Cc: Cristina Ciocan <cristina.ciocan@intel.com>
      Cc: stable@vger.kernel.org
      Fixes: 71e6ca61 ("pinctrl: baytrail: Register pin control handling")
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      a171bc51