Skip to content
  1. Mar 08, 2019
  2. Mar 07, 2019
  3. Mar 05, 2019
  4. Feb 24, 2019
    • Rajneesh Bhardwaj's avatar
      platform/x86: intel_pmc_core: Quirk to ignore XTAL shutdown · 238f9c11
      Rajneesh Bhardwaj authored
      On some platforms such as HP Elite-x2-1013-g3, the platform BIOS
      enforces XTAL to remain off before S0ix state can be achieved. This may
      not be optimum when we want to enable use cases like Low Power Audio,
      Wake on Voice etc which always need 24mhz clock.
      
      This introduces a new quirk to allow S0ix entry when all other
      conditions except for XTAL clock are good on a given platform. The extra
      power consumed by XTAL clock is about 2mw but it saves much more
      platform power compared to the system that remains in just PC10.
      
      Link: https://bit.ly/2UmnrFf
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=201579
      
      
      Tested-by: default avatar"David E. Box" <david.e.box@linux.intel.com>
      Reported-and-tested-by: default avatarrussianneuromancer <russianneuromancer@ya.ru>
      Signed-off-by: default avatarRajneesh Bhardwaj <rajneesh.bhardwaj@linux.intel.com>
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarDarren Hart (VMware) <dvhart@infradead.org>
      238f9c11
    • Rajneesh Bhardwaj's avatar
      platform/x86: intel_pmc_core: Add Package cstates residency info · 8aba056a
      Rajneesh Bhardwaj authored
      This patch introduces a new debugfs entry to read current Package
      cstate residency counters. A similar variant of this patch was discussed
      earlier "https://patchwork.kernel.org/patch/9908563/" but didn't make it
      into mainline for various reasons. Current version only adds debugfs
      entry which is quite useful for S0ix debug but excludes the exported API
      that was there in initial version. Though there are tools like turbostat
      and socwatch which can also show this info but sometimes its more
      practical to have it here as it's hard to switch between various tools for
      S0ix debug when pmc_core driver is the primary debug tool. Internal and
      external customers have requested for this patch to be included in the
      PMC driver on many occasions and Google Chrome OS team has already included
      it in their builds. This becomes handy when requesting logs from external
      customers who may not always have above mentioned tools in their integrated
      kernel builds.
      
      Package cstate residency MSRs provide useful debug information about
      system idle states. In idle states system must enter deeper Package
      cstates. Package cstates depend not only on Core cstates but also on
      various IP block's power gating status and LTR values.
      
      For Intel Core SoCs Package C10 entry is a must for deeper sleep states
      such as S0ix. "Suspend-to-idle"  should ideally take this path:
      PC0 -> PC10 -> S0ix. For S0ix debug, its logical to check for
      Package C10 residency first if for some reason system fails to enter S0ix.
      
      Please refer to this link for MSR details:
      https://software.intel.com/sites/default/files/managed/22/0d/335592-sdm-vol-4.pdf
      
      
      
      Usage:
      cat /sys/kernel/debug/pmc_core/package_cstate_show
      Package C2       : 0xec2e21735f
      Package C3       : 0xc30113ba4
      Package C6       : 0x9ef4be15c5
      Package C7       : 0x1e011904
      Package C8       : 0x3c5653cfe5a
      Package C9       : 0x0
      Package C10      : 0x16fff4289
      
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: "David E. Box" <david.e.box@intel.com>
      Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Cc: Anshuman Gupta <anshuman.gupta@intel.com>
      Cc: Len Brown <len.brown@intel.com>
      Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-and-tested-by: default avatarAnshuman Gupta <anshuman.gupta@intel.com>
      Signed-off-by: default avatarRajneesh Bhardwaj <rajneesh.bhardwaj@linux.intel.com>
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarDarren Hart (VMware) <dvhart@infradead.org>
      8aba056a
    • Rajneesh Bhardwaj's avatar
      platform/x86: intel_pmc_core: Add ICL platform support · 6769fdbe
      Rajneesh Bhardwaj authored
      
      
      Icelake can resue most of the CNL PCH IPs as they are mostly similar.
      This patch enables the PMC Core driver for ICL family.
      
      It also addresses few other minor issues like upper case conversions and
      some tab alignments.
      
      Cc: "David E. Box" <david.e.box@intel.com>
      Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Acked-and-tested-by: default avatarAnshuman Gupta <anshuman.gupta@intel.com>
      Signed-off-by: default avatarRajneesh Bhardwaj <rajneesh.bhardwaj@linux.intel.com>
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarDarren Hart (VMware) <dvhart@infradead.org>
      6769fdbe
    • Rajneesh Bhardwaj's avatar
      platform/x86: intel_pmc_core: Convert to INTEL_CPU_FAM6 macro · cfb55af9
      Rajneesh Bhardwaj authored
      
      
      INTEL_CPU_FAM6() macro provides better abstraction and reduces code size
      so use it instead of custom grown ICPU().
      
      Signed-off-by: default avatarRajneesh Bhardwaj <rajneesh.bhardwaj@linux.intel.com>
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarDarren Hart (VMware) <dvhart@infradead.org>
      cfb55af9
    • Rajneesh Bhardwaj's avatar
      x86/CPU: Add Icelake model number · ff7c634b
      Rajneesh Bhardwaj authored
      
      
      Add the CPUID model number of Icelake (ICL) mobile processors to the
      Intel family list. Icelake U/Y series uses model number 0x7E.
      
      Signed-off-by: default avatarRajneesh Bhardwaj <rajneesh.bhardwaj@linux.intel.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: "David E. Box" <david.e.box@intel.com>
      Cc: dvhart@infradead.org
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Kan Liang <kan.liang@linux.intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: platform-driver-x86@vger.kernel.org
      Cc: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
      Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: x86-ml <x86@kernel.org>
      Link: https://lkml.kernel.org/r/20190214115712.19642-2-rajneesh.bhardwaj@linux.intel.com
      
      
      Signed-off-by: default avatarDarren Hart (VMware) <dvhart@infradead.org>
      ff7c634b
    • Rajat Jain's avatar
      platform/x86: intel_pmc_core: Avoid a u32 overflow · 4a5861f7
      Rajat Jain authored
      
      
      The register (SLP_S0_RES) at offset slp_s0_offset is a 32 bit register.
      The pmc_core_adjust_slp_s0_step() could overflow the u32 value while
      returning it after adjusting the step. Thus change to u64, this is
      already accounted for in debugfs attribute (that wants to output a
      64 bit value).
      
      Signed-off-by: default avatarRajat Jain <rajatja@google.com>
      Acked-by: default avatarRajneesh Bhardwaj <rajneesh.bhardwaj@linux.intel.com>
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarDarren Hart (VMware) <dvhart@infradead.org>
      4a5861f7
    • Christoph Hellwig's avatar
      platform/x86: dell_rbu: fix lock imbalance in img_update_realloc · f27e1d18
      Christoph Hellwig authored
      
      
      We need to ensure rbu_data.lock is always held on return.
      
      Fixes: 289790a3ea94 ("platform/x86: dell_rbu: stop abusing the DMA API")
      Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Acked-by: default avatarStuart Hayes <stuart.w.hayes@gmail.com>
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarDarren Hart (VMware) <dvhart@infradead.org>
      f27e1d18
    • Mark Levedahl's avatar
      platform/x86: ideapad-laptop: Add Y530-I5ICH-1060 to no_hw_rfkill list · b7531859
      Mark Levedahl authored
      Commit 0252894f
      
       added the Legion Y530 to the no_hw_rfkill
      list, but missed a Y530 variant using the nvidia 1060 graphics card.
      I have had to blacklist ideapad-laptop as a result to get Wi-Fi working.
      
      dmidecode info:
      
      Handle 0x0001, DMI type 1, 27 bytes
      System Information
          Manufacturer: LENOVO
          Product Name: 81LB
          Version: Lenovo Legion Y530-15ICH-1060
          Serial Number: <snip>
          UUID: <snip>
          Wake-up Type: Power Switch
          SKU Number: LENOVO_MT_81LB_BU_idea_FM_Legion Y530-15ICH-1060
          Family: Legion Y530-15ICH-1060
      
      Signed-off-by: default avatarMark Levedahl <mlevedahl@gmail.com>
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarDarren Hart (VMware) <dvhart@infradead.org>
      b7531859
    • Vadim Pasternak's avatar
      leds: mlxreg: Add support for capability register · 530451d0
      Vadim Pasternak authored
      
      
      Add support for capability register in order to distinct between the
      systems with minor LED configuration differences. It reduces the amount
      of code describing systems' LED configuration.
      For example one system can be equipped with six LED, while the other
      with only four. Reading this information from the capability registers
      allows to use the same LED structure for such systems and set the
      relevant configuration dynamically based on capability register
      content.
      
      Signed-off-by: default avatarVadim Pasternak <vadimp@mellanox.com>
      Acked-by: default avatarJacek Anaszewski <jacek.anaszewski@gmail.com>
      Signed-off-by: default avatarDarren Hart (VMware) <dvhart@infradead.org>
      530451d0
    • Vadim Pasternak's avatar
      platform/mellanox: mlxreg-hotplug: Fix KASAN warning · e4c275f7
      Vadim Pasternak authored
      Fix the following KASAN warning produced when booting a 64-bit kernel:
      [   13.334750] BUG: KASAN: stack-out-of-bounds in find_first_bit+0x19/0x70
      [   13.342166] Read of size 8 at addr ffff880235067178 by task kworker/2:1/42
      [   13.342176] CPU: 2 PID: 42 Comm: kworker/2:1 Not tainted 4.20.0-rc1+ #106
      [   13.342179] Hardware name: Mellanox Technologies Ltd. MSN2740/Mellanox x86 SFF board, BIOS 5.6.5 06/07/2016
      [   13.342190] Workqueue: events deferred_probe_work_func
      [   13.342194] Call Trace:
      [   13.342206]  dump_stack+0xc7/0x15b
      [   13.342214]  ? show_regs_print_info+0x5/0x5
      [   13.342220]  ? kmsg_dump_rewind_nolock+0x59/0x59
      [   13.342234]  ? _raw_write_lock_irqsave+0x100/0x100
      [   13.351593]  print_address_description+0x73/0x260
      [   13.351603]  kasan_report+0x260/0x380
      [   13.351611]  ? find_first_bit+0x19/0x70
      [   13.351619]  find_first_bit+0x19/0x70
      [   13.351630]  mlxreg_hotplug_work_handler+0x73c/0x920 [mlxreg_hotplug]
      [   13.351639]  ? __lock_text_start+0x8/0x8
      [   13.351646]  ? _raw_write_lock_irqsave+0x80/0x100
      [   13.351656]  ? mlxreg_hotplug_remove+0x1e0/0x1e0 [mlxreg_hotplug]
      [   13.351663]  ? regmap_volatile+0x40/0xb0
      [   13.351668]  ? regcache_write+0x4c/0x90
      [   13.351676]  ? mlxplat_mlxcpld_reg_write+0x24/0x30 [mlx_platform]
      [   13.351681]  ? _regmap_write+0xea/0x220
      [   13.351688]  ? __mutex_lock_slowpath+0x10/0x10
      [   13.351696]  ? devm_add_action+0x70/0x70
      [   13.351701]  ? mutex_unlock+0x1d/0x40
      [   13.351710]  mlxreg_hotplug_probe+0x82e/0x989 [mlxreg_hotplug]
      [   13.351723]  ? mlxreg_hotplug_work_handler+0x920/0x920 [mlxreg_hotplug]
      [   13.351731]  ? sysfs_do_create_link_sd.isra.2+0xf4/0x190
      [   13.351737]  ? sysfs_rename_link_ns+0xf0/0xf0
      [   13.351743]  ? devres_close_group+0x2b0/0x2b0
      [   13.351749]  ? pinctrl_put+0x20/0x20
      [   13.351755]  ? acpi_dev_pm_attach+0x2c/0xd0
      [   13.351763]  platform_drv_probe+0x70/0xd0
      [   13.351771]  really_probe+0x480/0x6e0
      [   13.351778]  ? device_attach+0x10/0x10
      [   13.351784]  ? __lock_text_start+0x8/0x8
      [   13.351790]  ? _raw_write_lock_irqsave+0x80/0x100
      [   13.351797]  ? _raw_write_lock_irqsave+0x80/0x100
      [   13.351806]  ? __driver_attach+0x190/0x190
      [   13.351812]  driver_probe_device+0x17d/0x1a0
      [   13.351819]  ? __driver_attach+0x190/0x190
      [   13.351825]  bus_for_each_drv+0xd6/0x130
      [   13.351831]  ? bus_rescan_devices+0x20/0x20
      [   13.351837]  ? __mutex_lock_slowpath+0x10/0x10
      [   13.351845]  __device_attach+0x18c/0x230
      [   13.351852]  ? device_bind_driver+0x70/0x70
      [   13.351859]  ? __mutex_lock_slowpath+0x10/0x10
      [   13.351866]  bus_probe_device+0xea/0x110
      [   13.351874]  deferred_probe_work_func+0x1c9/0x290
      [   13.351882]  ? driver_deferred_probe_add+0x1d0/0x1d0
      [   13.351889]  ? preempt_notifier_dec+0x20/0x20
      [   13.351897]  ? read_word_at_a_time+0xe/0x20
      [   13.351904]  ? strscpy+0x151/0x290
      [   13.351912]  ? set_work_pool_and_clear_pending+0x9c/0xf0
      [   13.351918]  ? __switch_to_asm+0x34/0x70
      [   13.351924]  ? __switch_to_asm+0x40/0x70
      [   13.351929]  ? __switch_to_asm+0x34/0x70
      [   13.351935]  ? __switch_to_asm+0x40/0x70
      [   13.351942]  process_one_work+0x5cc/0xa00
      [   13.351952]  ? pwq_dec_nr_in_flight+0x1e0/0x1e0
      [   13.351960]  ? pci_mmcfg_check_reserved+0x80/0xb8
      [   13.351967]  ? run_rebalance_domains+0x250/0x250
      [   13.351980]  ? stack_access_ok+0x35/0x80
      [   13.351986]  ? deref_stack_reg+0xa1/0xe0
      [   13.351994]  ? schedule+0xcd/0x250
      [   13.352000]  ? worker_enter_idle+0x2d6/0x330
      [   13.352006]  ? __schedule+0xeb0/0xeb0
      [   13.352014]  ? fork_usermode_blob+0x130/0x130
      [   13.352019]  ? mutex_lock+0xa7/0x100
      [   13.352026]  ? _raw_spin_lock_irq+0x98/0xf0
      [   13.352032]  ? _raw_read_unlock_irqrestore+0x30/0x30
      [   13.352037] i2c i2c-2: Added multiplexed i2c bus 11
      [   13.352043]  worker_thread+0x181/0xa80
      [   13.352052]  ? __switch_to_asm+0x34/0x70
      [   13.352058]  ? __switch_to_asm+0x40/0x70
      [   13.352064]  ? process_one_work+0xa00/0xa00
      [   13.352070]  ? __switch_to_asm+0x34/0x70
      [   13.352076]  ? __switch_to_asm+0x40/0x70
      [   13.352081]  ? __switch_to_asm+0x34/0x70
      [   13.352086]  ? __switch_to_asm+0x40/0x70
      [   13.352092]  ? __switch_to_asm+0x34/0x70
      [   13.352097]  ? __switch_to_asm+0x40/0x70
      [   13.352105]  ? __schedule+0x3d6/0xeb0
      [   13.352112]  ? migrate_swap_stop+0x470/0x470
      [   13.352119]  ? save_stack+0x89/0xb0
      [   13.352127]  ? kmem_cache_alloc_trace+0xe5/0x570
      [   13.352132]  ? kthread+0x59/0x1d0
      [   13.352138]  ? ret_from_fork+0x35/0x40
      [   13.352154]  ? __schedule+0xeb0/0xeb0
      [   13.352161]  ? remove_wait_queue+0x150/0x150
      [   13.352169]  ? _raw_write_lock_irqsave+0x80/0x100
      [   13.352175]  ? __lock_text_start+0x8/0x8
      [   13.352183]  ? process_one_work+0xa00/0xa00
      [   13.352188]  kthread+0x1a4/0x1d0
      [   13.352195]  ? kthread_create_worker_on_cpu+0xc0/0xc0
      [   13.352202]  ret_from_fork+0x35/0x40
      
      [   13.353879] The buggy address belongs to the page:
      [   13.353885] page:ffffea0008d419c0 count:0 mapcount:0 mapping:0000000000000000 index:0x0
      [   13.353890] flags: 0x2ffff8000000000()
      [   13.353897] raw: 02ffff8000000000 ffffea0008d419c8 ffffea0008d419c8 0000000000000000
      [   13.353903] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
      [   13.353905] page dumped because: kasan: bad access detected
      
      [   13.353908] Memory state around the buggy address:
      [   13.353912]  ffff880235067000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      [   13.353917]  ffff880235067080: 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 04
      [   13.353921] >ffff880235067100: f2 f2 f2 f2 f2 f2 f2 04 f2 f2 f2 f2 f2 f2 f2 04
      [   13.353923]                                                                 ^
      [   13.353927]  ffff880235067180: f2 f2 f2 f2 f2 f2 f2 04 f2 f2 f2 00 00 00 00 00
      [   13.353931]  ffff880235067200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      [   13.353933] ==================================================================
      
      The warning is caused by the below loop:
      	for_each_set_bit(bit, (unsigned long *)&asserted, 8) {
      while "asserted" is declared as 'unsigned'.
      
      The casting of 32-bit unsigned integer pointer to a 64-bit unsigned long
      pointer. There are two problems here.
      It causes the access of four extra byte, which can corrupt memory
      The 32-bit pointer address may not be 64-bit aligned.
      
      The fix changes variable "asserted" to "unsigned long".
      
      Fixes: 1f976f69
      
       ("platform/x86: Move Mellanox platform hotplug driver to platform/mellanox")
      Signed-off-by: default avatarVadim Pasternak <vadimp@mellanox.com>
      Signed-off-by: default avatarDarren Hart (VMware) <dvhart@infradead.org>
      e4c275f7
    • Mattias Jacobsson's avatar
      platform/x86: wmi: fix potential null pointer dereference · c355ec65
      Mattias Jacobsson authored
      In the function wmi_dev_match() the variable id is dereferenced without
      first performing a NULL check. The variable can for example be NULL if
      a WMI driver is registered without specifying the id_table field in
      struct wmi_driver.
      
      Add a NULL check and return that the driver can't handle the device if
      the variable is NULL.
      
      Fixes: 844af950
      
       ("platform/x86: wmi: Turn WMI into a bus driver")
      Signed-off-by: default avatarMattias Jacobsson <2pi@mok.nu>
      Signed-off-by: default avatarDarren Hart (VMware) <dvhart@infradead.org>
      c355ec65
    • Christoph Hellwig's avatar
      platform/x86: dell_rbu: stop abusing the DMA API · fd47a36f
      Christoph Hellwig authored
      
      
      For some odd reason dell_rbu actually seems to want the physical and
      not a bus address for the allocated buffer.  Lets assume that actually
      is correct given that it is BIOS-related and that is a good source
      of insanity.  In that case we should not use dma_alloc_coherent with
      a NULL device to allocate memory, but use GFP_DMA32 to stay under
      the 32-bit BIOS limit.
      
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Acked-by: default avatarStuart Hayes <stuart.w.hayes@gmail.com>
      Signed-off-by: default avatarDarren Hart (VMware) <dvhart@infradead.org>
      fd47a36f
    • Yang Fan's avatar
      platform/x86: ideapad-laptop: Fix no_hw_rfkill_list for Lenovo RESCUER R720-15IKBN · 4d9b2864
      Yang Fan authored
      Commit ae7c8cba ("platform/x86: ideapad-laptop: add lenovo RESCUER
      R720-15IKBN to no_hw_rfkill_list") added
          DMI_MATCH(DMI_BOARD_NAME, "80WW")
      for Lenovo RESCUER R720-15IKBN.
      
      But DMI_BOARD_NAME does not match 80WW on Lenovo RESCUER R720-15IKBN,
      thus cause Wireless LAN still be hard blocked.
      
      On Lenovo RESCUER R720-15IKBN:
          ~$ cat /sys/class/dmi/id/sys_vendor
          LENOVO
          ~$ cat /sys/class/dmi/id/board_name
          Provence-5R3
          ~$ cat /sys/class/dmi/id/product_name
          80WW
          ~$ cat /sys/class/dmi/id/product_version
          Lenovo R720-15IKBN
      
      So on Lenovo RESCUER R720-15IKBN:
          DMI_SYS_VENDOR should match "LENOVO",
          DMI_BOARD_NAME should match "Provence-5R3",
          DMI_PRODUCT_NAME should match "80WW",
          DMI_PRODUCT_VERSION should match "Lenovo R720-15IKBN".
      
      Fix it, and in according with other entries in no_hw_rfkill_list,
      use DMI_PRODUCT_VERSION instead of DMI_BOARD_NAME.
      
      Fixes: ae7c8cba
      
       ("platform/x86: ideapad-laptop: add lenovo RESCUER R720-15IKBN to no_hw_rfkill_list")
      Signed-off-by: default avatarYang Fan <nullptr.cpp@gmail.com>
      Signed-off-by: default avatarDarren Hart (VMware) <dvhart@infradead.org>
      4d9b2864
    • Hans de Goede's avatar
      platform/x86: asus-wmi: Allow loading on systems without the Asus Management GUID · c994611a
      Hans de Goede authored
      
      
      hid-asus depends on asus-wmi through the asus_wmi_evaluate_method. Before
      this commit asus-wmi, and thus hid-asus, could not be loaded on non-Asus
      systems. This breaks using Asus bluetooth keyboards such as the Asus
      T100CHI keyboard with non Asus systems.
      
      This commit fixes this by allowing asus-wmi to load on systems without the
      Asus Management GUID.
      
      This is safe to do since all asus-wmi sub drivers use
      asus_wmi_register_driver which also checks for the GUID.
      
      This commit also improves the error messages in asus_wmi_register_driver
      to include "ASUS" in their description to make them more clear. This is
      important since we now rely on those errors when loaded on systems without
      the Asus Management GUID.
      
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarDarren Hart (VMware) <dvhart@infradead.org>
      c994611a
  5. Feb 21, 2019
  6. Feb 06, 2019