1. 04 11月, 2017 2 次提交
  2. 03 11月, 2017 1 次提交
  3. 28 10月, 2017 1 次提交
  4. 28 9月, 2017 1 次提交
  5. 20 9月, 2017 1 次提交
  6. 21 7月, 2017 1 次提交
    • A
      platform/x86: peaq-wmi: select INPUT_POLLDEV · a00c6963
      Arnd Bergmann 提交于
      The new driver fails to build without INPUT_POLLDEV
      
      drivers/platform/x86/peaq-wmi.o: In function `peaq_wmi_exit':
      peaq-wmi.c:(.exit.text+0x1c): undefined reference to `input_unregister_polled_device'
      drivers/platform/x86/peaq-wmi.o: In function `peaq_wmi_init':
      peaq-wmi.c:(.init.text+0x23): undefined reference to `input_allocate_polled_device'
      peaq-wmi.c:(.init.text+0x18e): undefined reference to `input_register_polled_device'
      
      For some reason, all other drivers that need this use 'select'
      here rather than 'depends on', so I'm doing the same.
      
      Fixes: 13bb0fd5 ("platform/x86: peaq-wmi: Add new peaq-wmi driver")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>
      a00c6963
  7. 01 7月, 2017 1 次提交
    • M
      platform/x86: fujitsu-laptop: rework debugging · eee77da1
      Michał Kępień 提交于
      Using a dedicated Kconfig option for enabling debugging means the user
      may be forced to recompile their kernel in order to gather debugging
      information, which is inconvenient.  Replace custom debugging
      infrastructure with standard logging functions, taking advantage of
      dynamic debug.  Replace a pr_info() call inside an ACPI callback with an
      acpi_handle_info() call.
      
      The following mapping was used:
      
        - FUJLAPTOP_DBG_ERROR -> acpi_handle_err()
        - FUJLAPTOP_DBG_WARN  -> acpi_handle_info() / dev_info()
        - FUJLAPTOP_DBG_INFO  -> acpi_handle_debug()
        - FUJLAPTOP_DBG_TRACE -> acpi_handle_debug() / dev_dbg()
      
      This means that some events which used to only be logged when the user
      explicitly requested it will now be logged by default:
      
        - ACPI method evaluation errors,
        - unknown ACPI notification codes,
        - unknown hotkey scancodes.
      
      The first type of events should happen rarely, if ever at all.  The rest
      is interesting from driver development perspective as their presence in
      the logs will mean the driver is unaware of certain events, handling of
      which should be implemented.
      Signed-off-by: NMichał Kępień <kernel@kempniu.pl>
      Reviewed-by: NJonathan Woithe <jwoithe@just42.net>
      Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>
      eee77da1
  8. 15 6月, 2017 1 次提交
  9. 07 6月, 2017 1 次提交
  10. 15 5月, 2017 1 次提交
    • H
      platform/x86: peaq-wmi: Add new peaq-wmi driver · 13bb0fd5
      Hans de Goede 提交于
      PEAQ is a new European OEM, I've bought one of their 2-in-1 x86 devices,
      which is actually quite a nice device. Under Windows it has Dolby
      software for "better" sound and you can select different equalizer
      presets using a special button.
      
      This WMI interface for this button is not really nice, as it does not do
      notifies (it really does not I triple checked), but since I had already
      figured out the entire WMI interface for this I decided to go the full
      mile anyway and implement a WMI based input driver for this using
      input_polldev since, well, we need to poll.
      
      This commit adds support for this button making it report KEY_SOUND
      input events. KEY_SOUND is already used in various places to switch
      sound into theatre mode and things like that so it seems appropriate
      here.
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
      Reviewed-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      [dvhart: minor declaration ordering and commit log typo fixes]
      Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>
      13bb0fd5
  11. 29 4月, 2017 1 次提交
  12. 27 4月, 2017 1 次提交
  13. 22 4月, 2017 1 次提交
    • T
      platform/x86: INT33FE: add i2c dependency · 58688a75
      Tobias Regnery 提交于
      With CONFIG_I2C=m and CONFIG_INTEL_CHT_INT33FE=y we see the following link
      errors:
      
      drivers/built-in.o: In function 'cht_int33fe_remove':
      intel_cht_int33fe.c:(.text+0x391f6e): undefined reference to 'i2c_unregister_device'
      intel_cht_int33fe.c:(.text+0x391f76): undefined reference to 'i2c_unregister_device'
      intel_cht_int33fe.c:(.text+0x391f7d): undefined reference to 'i2c_unregister_device'
      drivers/built-in.o: In function 'cht_int33fe_probe':
      intel_cht_int33fe.c:(.text+0x392147): undefined reference to 'i2c_acpi_new_device'
      intel_cht_int33fe.c:(.text+0x392185): undefined reference to 'i2c_acpi_new_device'
      intel_cht_int33fe.c:(.text+0x3921bd): undefined reference to 'i2c_acpi_new_device'
      intel_cht_int33fe.c:(.text+0x3921d9): undefined reference to 'i2c_unregister_device'
      intel_cht_int33fe.c:(.text+0x3921e8): undefined reference to 'i2c_unregister_device'
      drivers/built-in.o: In function 'cht_int33fe_driver_init':
      intel_cht_int33fe.c:(.init.text+0x2386d): undefined reference to 'i2c_register_driver'
      drivers/built-in.o: In function 'cht_int33fe_driver_exit':
      intel_cht_int33fe.c:(.exit.text+0x206e): undefined reference to 'i2c_del_driver'
      
      Fix this by adding a kconfig dependency on the I2C subsystem.
      
      Fixes: 1cd706df ("platform/x86: Add Intel Cherry Trail ACPI INT33FE device driver")
      Signed-off-by: NTobias Regnery <tobias.regnery@gmail.com>
      Reviewed-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>
      58688a75
  14. 20 4月, 2017 1 次提交
  15. 18 4月, 2017 1 次提交
  16. 14 4月, 2017 1 次提交
  17. 07 3月, 2017 1 次提交
  18. 14 2月, 2017 2 次提交
  19. 04 2月, 2017 1 次提交
    • S
      platform/x86: Support Turbo Boost Max 3.0 for non HWP systems · 4ec567b8
      Srinivas Pandruvada 提交于
      On platforms supporting Intel Turbo Boost Max Technology 3.0, the
      maximum turbo frequencies (turbo ratio) of some cores in a CPU package
      may be higher than the other cores in the same package.  In that case,
      better performance can be achieved by making the scheduler prefer to run
      tasks on the CPUs with higher max turbo frequencies.
      
      On Intel® Broadwell Xeon systems, it is optional to turn on HWP
      (Hardware P-States). When HWP is not turned on, the BIOS doesn't
      present required CPPC (Collaborative Processor Performance Control)
      tables. This table is used to get the per CPU core maximum performance
      ratio and inform scheduler (in cpufreq/intel_pstate driver).
      
      On such systems the maximum performance ratio can be read via over
      clocking (OC) mailbox interface for each CPU. This interface is not
      architectural and can change for every model of processors.
      
      This driver reads maximum performance ratio of each CPU and set up
      the scheduler priority metrics. In this way scheduler can prefer CPU
      with higher performance to schedule tasks.
      Signed-off-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Signed-off-by: NDarren Hart <dvhart@linux.intel.com>
      4ec567b8
  20. 03 2月, 2017 1 次提交
    • J
      platform/x86: dell-smbios: Auto-select as needed · 9893ae86
      Jean Delvare 提交于
      Dell-smbios is a helper module, it serves no purpose on its own, so
      do not present it as an option to the user. Instead, select it
      automatically whenever a driver which needs it is selected.
      
      Also select DCDBAS as needed, instead of depending on it, so that
      the Dell driver options are always visible.
      
      As a clean-up, I removed the "default n" statements as they are not
      needed (n is the default default.)
      Signed-off-by: NJean Delvare <jdelvare@suse.de>
      Cc: Michał Kępień <kernel@kempniu.pl>
      Cc: Pali Rohár <pali.rohar@gmail.com>
      Cc: Darren Hart <dvhart@infradead.org>
      Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      9893ae86
  21. 27 1月, 2017 2 次提交
  22. 14 1月, 2017 1 次提交
  23. 28 12月, 2016 1 次提交
  24. 19 12月, 2016 1 次提交
  25. 17 12月, 2016 3 次提交
  26. 23 10月, 2016 1 次提交
    • V
      platform/x86: Introduce support for Mellanox hotplug driver · 30488704
      Vadim Pasternak 提交于
      Enable system support for the Mellanox Technologies hotplug platform
      driver, which provides support for the next Mellanox basic systems:
      "msx6710", "msx6720", "msb7700", "msn2700", "msx1410", "msn2410",
      "msb7800", "msn2740", "msn2100" and also various number of derivative
      systems from the above basic types.
      This driver handles hot-plug events for the power suppliers, power
      cables and fans for the above systems.
      
      The Kconfig currently controlling compilation of this code is:
      driver/platform/x86:config MLX_CPLD_PLATFORM
                             tristate "Mellanox platform hotplug driver support"
      Signed-off-by: NVadim Pasternak <vadimp@mellanox.com>
      Signed-off-by: NDarren Hart <dvhart@linux.intel.com>
      30488704
  27. 13 10月, 2016 1 次提交
    • A
      platform/x86: asus-wmi: add SERIO_I8042 dependency · ea893695
      Arnd Bergmann 提交于
      A recent bugfix added a call to i8042_install_filter but did
      not add the dependency, leading to possible link errors:
      
      drivers/platform/built-in.o: In function `asus_nb_wmi_quirks':
      asus-nb-wmi.c:(.text+0x23af): undefined reference to `i8042_install_filter'
      
      This adds a dependency on SERIO_I8042||SERIO_I8042=n to indicate
      that we can build the driver when the i8042 driver is disabled,
      but it cannot be built-in when that is a loadable module.
      
      Fixes: b5643539 ("platform/x86: asus-wmi: Filter buggy scan codes on ASUS Q500A")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NDarren Hart <dvhart@linux.intel.com>
      ea893695
  28. 23 7月, 2016 1 次提交
  29. 02 7月, 2016 1 次提交
    • J
      asus-wireless: Toggle airplane mode LED · 2c1a49c9
      João Paulo Rechi Vita 提交于
      In the ASHS device we have the HSWC method, which calls either OWGD or
      OWGS, depending on its parameter:
      
      	Device (ASHS)
      	{
      		Name (_HID, "ATK4002")  // _HID: Hardware ID
      		Method (HSWC, 1, Serialized)
      		{
      			If ((Arg0 < 0x02))
      			{
      				OWGD (Arg0)
      				Return (One)
      			}
      			If ((Arg0 == 0x02))
      			{
      				Local0 = OWGS ()
      				If (Local0)
      				{
      					Return (0x05)
      				}
      				Else
      				{
      					Return (0x04)
      				}
      			}
      			If ((Arg0 == 0x03))
      			{
      				Return (0xFF)
      			}
      			If ((Arg0 == 0x04))
      			{
      				OWGD (Zero)
      				Return (One)
      			}
      			If ((Arg0 == 0x05))
      			{
      				OWGD (One)
      				Return (One)
      			}
      			If ((Arg0 == 0x80))
      			{
      				Return (One)
      			}
      		}
      		Method (_STA, 0, NotSerialized)  // _STA: Status
      		{
      			If ((MSOS () >= OSW8))
      			{
      				Return (0x0F)
      			}
      			Else
      			{
      				Return (Zero)
      			}
      		}
      	}
      
      On the Asus laptops that do not have an airplane mode LED, OWGD has an
      empty implementation and OWGS simply returns 0. On the ones that have an
      airplane mode LED these methods have the following implementation:
      
      	Method (OWGD, 1, Serialized)
      	{
      		SGPL (0x0203000F, Arg0)
      		SGPL (0x0203000F, Arg0)
      	}
      
      	Method (OWGS, 0, Serialized)
      	{
      		Store (RGPL (0x0203000F), Local0)
      		Return (Local0)
      	}
      
      Where OWGD(1) sets the airplane mode LED ON, OWGD(0) set it off, and
      OWGS() returns its state.
      
      This commit exposes the airplane mode indicator LED to userspace under
      the name asus-wireless::airplane, so it can be driven according to
      userspace's policy.
      Signed-off-by: NJoão Paulo Rechi Vita <jprvita@endlessm.com>
      Reviewed-by: NCorentin Chary <corentin.chary@gmail.com>
      Signed-off-by: NDarren Hart <dvhart@linux.intel.com>
      2c1a49c9
  30. 29 6月, 2016 1 次提交
  31. 09 6月, 2016 1 次提交
  32. 28 5月, 2016 1 次提交
    • R
      platform/x86: Add PMC Driver for Intel Core SoC · b740d2e9
      Rajneesh Bhardwaj 提交于
      This patch adds the Power Management Controller driver as a PCI driver
      for Intel Core SoC architecture.
      
      This driver can utilize debugging capabilities and supported features
      as exposed by the Power Management Controller.
      
      Please refer to the below specification for more details on PMC features.
      http://www.intel.in/content/www/in/en/chipsets/100-series-chipset-datasheet-vol-2.html
      
      The current version of this driver exposes SLP_S0_RESIDENCY counter.
      This counter can be used for detecting fragile SLP_S0 signal related
      failures and take corrective actions when PCH SLP_S0 signal is not
      asserted after kernel freeze as part of suspend to idle flow
      (echo freeze > /sys/power/state).
      
      Intel Platform Controller Hub (PCH) asserts SLP_S0 signal when it
      detects favorable conditions to enter its low power mode. As a
      pre-requisite the SoC should be in deepest possible Package C-State
      and devices should be in low power mode. For example, on Skylake SoC
      the deepest Package C-State is Package C10 or PC10. Suspend to idle
      flow generally leads to PC10 state but PC10 state may not be sufficient
      for realizing the platform wide power potential which SLP_S0 signal
      assertion can provide.
      
      SLP_S0 signal is often connected to the Embedded Controller (EC) and the
      Power Management IC (PMIC) for other platform power management related
      optimizations.
      
      In general, SLP_S0 assertion == PC10 + PCH low power mode + ModPhy Lanes
      power gated + PLL Idle.
      
      As part of this driver, a mechanism to read the SLP_S0_RESIDENCY is exposed
      as an API and also debugfs features are added to indicate SLP_S0 signal
      assertion residency in microseconds.
      
      echo freeze > /sys/power/state
      wake the system
      cat /sys/kernel/debug/pmc_core/slp_s0_residency_usec
      Signed-off-by: NRajneesh Bhardwaj <rajneesh.bhardwaj@intel.com>
      Signed-off-by: NVishwanath Somayaji <vishwanath.somayaji@intel.com>
      Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: NDarren Hart <dvhart@linux.intel.com>
      b740d2e9
  33. 24 3月, 2016 3 次提交