1. 08 May, 2019 8 commits
    • Andy Shevchenko's avatar
      platform/x86: Add support for Basin Cove power button · 6456fd73
      Andy Shevchenko authored
      This provides a new input driver for supporting the power button on
      Basin Cove PMIC, found on Intel Merrifield-based devices.
      
      The driver follows the design used in intel_chtdc_ti_pwrbtn.c module.
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      6456fd73
    • Chris Chiu's avatar
      platform/x86: asus-wmi: Add fn-lock mode switch support · 487579ba
      Chris Chiu authored
      Some of latest ASUS laptops support new fn-lock mode switching.
      This commit detect whether if the fn-lock option is enabled in
      BIOS setting, and toggle the fn-lock mode via a new WMI DEVID
      0x00100023 when the corresponding notify code captured.
      
      The ASUS fn-lock mode switch is activated by pressing Fn+Esc.
      When on, keys F1 to F12 behave as applicable, with meanings
      defined by the application being used at the time. When off,
      F1 to F12 directly triggers hardware features, well known audio
      volume up/down, brightness up/down...etc, which were triggered
      by holding down Fn key and F-keys.
      
      Because there's no way to retrieve the fn-lock mode via existing
      WMI methods per ASUS spec, driver need to initialize and keep the
      fn-lock mode by itself.
      Signed-off-by: default avatarChris Chiu <chiu@endlessm.com>
      Reviewed-by: default avatarDaniel Drake <drake@endlessm.com>
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      487579ba
    • Hans de Goede's avatar
      platform/x86: ideapad-laptop: Remove no_hw_rfkill_list · 5105e78e
      Hans de Goede authored
      When the ideapad-laptop driver was first written it was written for laptops
      which had a hardware rfkill switch. So when the first ideapad laptops
      showed up without a hw rfkill switch and it turned out that in this case
      the ideapad firmware interface would always report the wifi being hardware-
      blocked, a DMI id list of models which lack a hw rfkill switch was started
      (by yours truly). Things were done this way to avoid regressing existing
      models with a hw rfkill switch. In hindsight this was a mistake.
      
      Lenovo releases a lot of ideapad models every year and even the latest
      models still use the "VPC2004" ACPI interface the ideapad-laptop driver
      binds to. Having a hw rfkill switch is quite rare on modern hardware, so
      all these new models need to be added to the no_hw_rfkill_list, leading
      to a never ending game of whack a mole.
      
      Worse the failure mode when not present on the list, is very bad. In this
      case the ideapad-laptop driver will report the wifi as being hw-blocked,
      at which points NetworkManager does not even try to use it and the user
      ends up with non working wifi.
      
      This leads to various Linux fora on the internet being filled with
      wifi not working on ideapad laptops stories, which does not make Linux
      look good.
      
      The failure mode when we flip the default to assuming that a hw rfkill
      switch is not present OTOH is quite benign. When we properly report the
      wifi as being hw-blocked on ideapads which do have the hw-switch; and it
      is in the wifi-off position, then at least when using NetworkManager +
      GNOME3 the user will get a "wifi disabled in hardware" message when trying
      to connect to the wifi from the UI. If OTOH we assume there is no hardware
      rfkill switch, then the user will get an empty list for the list of
      available networks. Although the empty list vs the "wifi disabled in
      hardware" message is a regression, it is a very minor regression and it
      can easily be fixed on a model by model basis by filling the new
      hw_rfkill_list this commit introduces.
      
      Therefor this commit removes the ever growing no_hw_rfkill_list, flipping
      the default to assuming there is no hw rfkill switch and adding a new
      hw_rfkill_list. Thereby fixing the wifi not working on all the current
      ideapad and yoga models which are not on the list yet and also fixing it
      for all future ideapad and yoga models using the "VPC2004" ACPI interface.
      
      Note once this patch has been accepted upstream. I plan to write a blog
      post asking for users of ideapads and yoga's with a hw rfkill switch to
      step forward, so that we can populate the new hw_rfkill_list with the few
      older yoga and ideapad models which actually have a hw rfkill switch.
      
      BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1703338Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      5105e78e
    • Benjamin Renz's avatar
      platform/x86: touchscreen_dmi: Add info for 'jumper ezpad 6 pro b' touchscreen · 504a4351
      Benjamin Renz authored
      Add touchscreen platform data for the 'jumper ezpad 6 pro b' touchscreen.
      Signed-off-by: default avatarBenjamin Renz <appswert@gmail.com>
      [hdegoede@redhat.com: Cleanup commit msg, fix some checkpatch warnings]
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      504a4351
    • Pavel Machek's avatar
      platform/x86: thinkpad_acpi: cleanup for Thinkpad ACPI led · aac3311c
      Pavel Machek authored
      Make error returns more consistent... no behaviour change intended.
      Signed-off-by: default avatarPavel Machek <pavel@ucw.cz>
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      aac3311c
    • Gustavo A. R. Silva's avatar
      platform/x86: thinkpad_acpi: Mark expected switch fall-throughs · c77c3577
      Gustavo A. R. Silva authored
      In preparation to enabling -Wimplicit-fallthrough, mark switch
      cases where we are expecting to fall through.
      
      This patch fixes the following warnings:
      
      drivers/platform/x86/thinkpad_acpi.c: In function ‘thermal_get_sensor’:
      drivers/platform/x86/thinkpad_acpi.c:6316:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
         if (idx >= 8 && idx <= 15) {
            ^
      drivers/platform/x86/thinkpad_acpi.c:6322:2: note: here
        case TPACPI_THERMAL_TPEC_8:
        ^~~~
      drivers/platform/x86/thinkpad_acpi.c: In function ‘hotkey_notify’:
      drivers/platform/x86/thinkpad_acpi.c:4208:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
          if (tp_features.hotkey_wlsw &&
             ^
      drivers/platform/x86/thinkpad_acpi.c:4216:3: note: here
         default:
         ^~~~~~~
      
      Warning level 3 was used: -Wimplicit-fallthrough=3
      
      Notice that, in this particular case, the code comments are modified
      in accordance with what GCC is expecting to find.
      
      This patch is part of the ongoing efforts to enable
      -Wimplicit-fallthrough.
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
      Acked-by: default avatarHenrique de Moraes Holschuh <hmh@hmh.eng.br>
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      c77c3577
    • Gustavo A. R. Silva's avatar
      platform/x86: sony-laptop: Fix unintentional fall-through · 1cbd7a64
      Gustavo A. R. Silva authored
      It seems that the default case should return AE_CTRL_TERMINATE, instead
      of falling through to case ACPI_RESOURCE_TYPE_END_TAG and returning AE_OK;
      otherwise the line of code at the end of the function is unreachable and
      makes no sense:
      
      return AE_CTRL_TERMINATE;
      
      This fix is based on the following thread of discussion:
      
      https://lore.kernel.org/patchwork/patch/959782/
      
      Fixes: 33a04454 ("sony-laptop: Add SNY6001 device handling (sonypi reimplementation)")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      1cbd7a64
    • Dan Carpenter's avatar
      platform/x86: alienware-wmi: printing the wrong error code · 6d1f8b3d
      Dan Carpenter authored
      The "out_data" variable is uninitialized at the point.  Originally, this
      used to print "status" instead and that seems like the correct thing to
      print.
      
      Fixes: bc2ef884 ("alienware-wmi: For WMAX HDMI method, introduce a way to query HDMI cable status")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Reviewed-by: default avatarMario Limonciello <mario.limonciello@dell.com>
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      6d1f8b3d
  2. 06 May, 2019 10 commits
  3. 16 Apr, 2019 2 commits
  4. 08 Apr, 2019 6 commits
  5. 17 Mar, 2019 14 commits