- 07 Mar, 2019 5 commits
-
-
Mattias Jacobsson authored
WMI drivers can if they have specified an array of struct wmi_device_id use the MODULE_DEVICE_TABLE() macro to automatically generate the appropriate MODULE_ALIAS() output. Thus avoiding to keep both the array of struct wmi_device_id and the MODULE_ALIAS() declaration(s) in sync. Change driver to use MODULE_DEVICE_TABLE() instead of MODULE_ALIAS(). Signed-off-by:
Mattias Jacobsson <2pi@mok.nu> Reviewed-by:
Mario Limonciello <mario.limonciello@dell.com> Signed-off-by:
Darren Hart (VMware) <dvhart@infradead.org>
-
Mattias Jacobsson authored
WMI drivers can if they have specified an array of struct wmi_device_id use the MODULE_DEVICE_TABLE() macro to automatically generate the appropriate MODULE_ALIAS() output. Thus avoiding to keep both the array of struct wmi_device_id and the MODULE_ALIAS() declaration(s) in sync. Change driver to use MODULE_DEVICE_TABLE() instead of MODULE_ALIAS(). Signed-off-by:
-
Mattias Jacobsson authored
The kernel provides the macro MODULE_DEVICE_TABLE() where driver authors can specify their device type and their array of device_ids and thereby trigger the generation of the appropriate MODULE_ALIAS() output. This is opposed to having to specify one MODULE_ALIAS() for each device. The WMI device type is currently not supported. While using MODULE_DEVICE_TABLE() does increase the complexity as well as spreading out the implementation across the kernel, it does come with some benefits too; * It makes different drivers look more similar; if you can specify the array of device_ids any device type specific input to MODULE_ALIAS() will automatically be generated for you. * It helps each driver avoid keeping multiple versions of the same information in sync. That is, both the array of device_ids and the potential multitude of MODULE_ALIAS()'s. Add WMI support to MODULE_DEVICE_TABLE() by adding info about struct wmi_device_id in devicetable-offsets.c and add a WMI entry point in file2alias.c. The type argument for MODULE_DEVICE_TABLE(type, name) is wmi. Suggested-by:
Pali Rohár <pali.rohar@gmail.com> Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by:
-
Mattias Jacobsson authored
In preparation for adding WMI support to MODULE_DEVICE_TABLE() move the definition of struct wmi_device_id to mod_devicetable.h and inline guid_string in the struct. Changing guid_string to an inline char array changes the loop conditions when looping over an array of struct wmi_device_id. Therefore update wmi_dev_match()'s loop to check for an empty guid_string instead of a NULL pointer. Signed-off-by:
-
Mattias Jacobsson authored
The size of the variable alias provided to do_entry functions are currently not readily available. Thus hindering do_entry functions to perform bounds checking. Define the macro ALIAS_SIZE containing the size of the variable alias. Signed-off-by:
-
- 05 Mar, 2019 3 commits
-
-
Christian Oder authored
Add touchscreen info for the CHUWUI Hi10 Air tablet. Signed-off-by:
Christian Oder <me@myself5.de> Reviewed-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
-
Kai-Heng Feng authored
This platform doesn't have hardware switch for rfkill, so add it to no_hw_rfkill list to prevent wireless gets hard-blocked. BugLink: https://bugs.launchpad.net/bugs/1818204Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by:
-
Hugo Trovao authored
Lenovo Yoga C930 does not have a physical hw radio switch which makes ideapad_laptop to incorrectly disable radio while it should be working fine. Adding it to the no_hw_rfkill_list makes wireless available again without having to unload the module. Signed-off-by:
Hugo Trovao <htrovao@gmail.com> Signed-off-by:
-
- 23 Feb, 2019 14 commits
-
-
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=201579Tested-by:
"David E. Box" <david.e.box@linux.intel.com> Reported-and-tested-by:
russianneuromancer <russianneuromancer@ya.ru> Signed-off-by:
Rajneesh Bhardwaj <rajneesh.bhardwaj@linux.intel.com> Signed-off-by:
-
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:
Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by:
-
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:
-
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:
-
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:
Borislav 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.comSigned-off-by:
-
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:
Rajat Jain <rajatja@google.com> Acked-by:
-
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:Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Christoph Hellwig <hch@lst.de> Acked-by:
Stuart Hayes <stuart.w.hayes@gmail.com> Signed-off-by:
-
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:
Mark Levedahl <mlevedahl@gmail.com> Signed-off-by:
-
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:
Vadim Pasternak <vadimp@mellanox.com> Acked-by:
Jacek Anaszewski <jacek.anaszewski@gmail.com> Signed-off-by:
-
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: -
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:
-
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:
-
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:
Yang Fan <nullptr.cpp@gmail.com> Signed-off-by:
-
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:
-
- 21 Feb, 2019 2 commits
-
-
Rajneesh Bhardwaj authored
Recently introduced commit "platform/x86: intel_pmc_core: Show Latency Tolerance info <51337cd94d18184601ac0fb4cf1a02b8bbabc3d7> skipped the LTR from a reserved IP. Though this doesn't cause any functional issue but it is needed for the consumers of "ltr_ignore" as the index printing for "ltr_show" is missing. For example, w/o this change, a user that wants to ignore LTR from ME would do something like echo 5 > ltr_ignore but the index for ME is 6. Printing a reserved IP helps to properly calculate LTR ignore offsets. Cc: "David E. Box" <david.e.box@intel.com> Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by:
-
Rajneesh Bhardwaj authored
File permissions for ltr_show attribute should be similar to other debugfs attributes created by this driver. '0644' should be used only when there is a write operation desired such as for ltr_ignore. Cc: "David E. Box" <david.e.box@intel.com> Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Fixes: 2eb15055 ("platform/x86: intel_pmc_core: Show Latency Tolerance info") Signed-off-by:
-
- 05 Feb, 2019 9 commits
-
-
Rajneesh Bhardwaj authored
For Cannonlake and Icelake, the IP name for Res_6 should be SPF i.e. South Port F. No functional change is intended other than just renaming the IP appropriately. Cc: "David E. Box" <david.e.box@intel.com> Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Fixes: 291101f6 ("platform/x86: intel_pmc_core: Add CannonLake PCH support") Signed-off-by:
-
Rajneesh Bhardwaj authored
A previous commit "platform/x86: intel_pmc_core: Make the driver PCH family agnostic <c977b98b>" provided better abstraction to this driver but has some fundamental issues. e.g. the following condition for (index = 0; index < pmcdev->map->ppfear_buckets && index < PPFEAR_MAX_NUM_ENTRIES; index++, iter++) is wrong because for CNL, PPFEAR_MAX_NUM_ENTRIES is hardcoded as 5 which is _wrong_ and even though ppfear_buckets is 8, the loop fails to read all eight registers needed for CNL PCH i.e. PPFEAR0 and PPFEAR1. This patch refactors the pfear show logic to correctly read PCH IP power gating status for Cannonlake and beyond. Cc: "David E. Box" <david.e.box@intel.com> Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Fixes: c977b98b ("platform/x86: intel_pmc_core: Make the driver PCH family agnostic") Signed-off-by:
-
Rajneesh Bhardwaj authored
Only Coffeelake should use Cannonlake regmap other than Cannonlake platform. This allows Coffeelake special handling only when there is no matching PCI device and default reg map selected as per CPUID is for Sunrisepoint PCH. This change is needed to enable support for newer SoCs such as Icelake. Cc: "David E. Box" <david.e.box@intel.com> Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Fixes: 661405bd ("platform/x86: intel_pmc_core: Special case for Coffeelake") Acked-by:
-
Hans de Goede authored
Commit c3b8e884 ("platform/x86: intel_int0002_vgpio: Implement irq_set_wake"), was written to fix some wakeup issues on Bay Trail (BYT) devices. We've received a bug report that this causes a suspend regression on some Cherry Trail (CHT) based devices. To fix the issues this causes on CHT devices, this commit modifies the irq_set_wake support so that we only implement irq_set_wake on BYT devices, Fixes: c3b8e884 ("platform/x86: intel_int0002_vgpio: ... irq_set_wake") Reported-and-tested-by:
Maxim Mikityanskiy <maxtram95@gmail.com> Signed-off-by:
-
Anthony Wong authored
Lenovo ideapad 330-15ICH does not have hardware radio switch but driver wrongly reports all radios as hard-blocked, add it to no_hw_rfkill to fix it. BugLink: https://bugs.launchpad.net/bugs/1811815Signed-off-by:
Anthony Wong <anthony.wong@ubuntu.com> Signed-off-by:
-
Kai Renzig authored
Add touchscreen platform data for the Chuwi Hi8 Air tablet. Signed-off-by:
Kai Renzig <k.renzig@gmail.com> [andy: fixed driver name and rewrote subject] Signed-off-by:
-
Hans de Goede authored
Add touchscreen info for the Point of View Wintab P1006w (v1.0) tablet. Signed-off-by:
-
Kai-Heng Feng authored
There's a new wmi event generated by dell-wmi when pressing keyboard backlight hotkey: [ 3285.474172] dell_wmi: Unknown key with type 0x0010 and code 0x003f pressed This event is for notification purpose, let's ignore it. The keyboard backlight hotkey uses another event so it still works without event 0x3f. Signed-off-by:
-
Hans de Goede authored
The Point of View TAB-P1006W-232-3G tablet has an ACPI firmware node with a HID of BSG2150 describing the 2 Bosch sensors used in the device a BMC150 compatible accelerometer and a BMC150 compatible magnetometer. The ACPI firmware node actually contains 3 I2cSerialBusV2 resources, but this seems to be a copy and paste job from the BSG1160 firmware node on other devices, since there is no i2c-client listening to the 0x68 address listed in the third resource and the 0x68 address is identical to the address of the third resource in the BSG1160 nodes, where as the other 2 addresses are different. Add the ID to the I2C multi instantiate list, so that the i2c-multi-instantiate.c driver can handle it; And add the necessary info to the i2c-multi-instantiate.c driver to enumerate all I2C slaves correctly. To avoid triggering the: if (i < multi->num_clients) { dev_err(dev, "Error finding driver, idx %d\n", i); Error this commit lists the 3th device in the i2c_inst_data with a type of "bsg2150_dummy_dev". Signed-off-by:Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
- 26 Jan, 2019 7 commits
-
-
Vadim Pasternak authored
Add support for new Mellanox system type MSN3700C, which is a cost reduced flavor of the MSN37 system class. Signed-off-by:
-
Vadim Pasternak authored
Provide support for the fan capability registers for the next generation systems of types MQM87xx, MSN34xx, MSN37xx. These new registers provide configuration for tachometers and fan drawers connectivity. Use these registers for next generation led, fan and hotplug structures in order to distinguish between the systems which have minor configuration differences. This reduces the amount of code used to describe such systems. Signed-off-by:
-
Vadim Pasternak authored
Add capability field to "mlxreg_core_platform_data" structure. The purpose of this register is to provide additional info to platform driver through the atribute related capability register. Signed-off-by:
-
Vadim Pasternak authored
Remove "led" from the description, since the structure "mlxreg_core_platform_data" is used not only for led data. Signed-off-by:
-
Vadim Pasternak authored
Add documentation for the new attribute fan_dir (fan direction for systems of types MQM87xx, MSN34xx, MSN37xx. Signed-off-by:
-
Vadim Pasternak authored
Provide support for the fan direction register. This register shows configuration for system fans direction, which could be forward or reversed. For forward direction - relevant bit is set 0; For reversed direction - relevant bit is set 1. Signed-off-by:
-
Darren Hart (VMware) authored
The mlxreg-io for the merge window assumed 4.21 as the next kernel version. Replace 4.21 with 5.0. Signed-off-by:
Andy Shevchenko <andy.shevchenko@gmail.com>
-
