- 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:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Darren Hart (VMware) <dvhart@infradead.org>
-
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:
Mattias Jacobsson <2pi@mok.nu> 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:
Hans de Goede <hdegoede@redhat.com> 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:
Kai-Heng Feng <kai.heng.feng@canonical.com> Reviewed-by:
Pali Rohár <pali.rohar@gmail.com> 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 8 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>
-
Jérôme de Bretagne authored
Power button suspend for some Dell models was added in: commit 821b8536 ("platform/x86: intel-hid: Power button suspend on Dell Latitude 7275") by checking against the power button press notification (0xCE) to report the power button press event. The corresponding power button release notification (0xCF) was caught and ignored to stop it from being reported as an "unknown event" in the logs. The missing button release event is creating issues on Android-x86, as reported on the project mailing list for a Dell Latitude 5175 model, since the events are expected in down/up pairs. Report the power button release event to fix this issue. Link: https://groups.google.com/forum/#!topic/android-x86/aSwZK9Nf9RoTested-by:
Tristian Celestin <tristian.celestin@outlook.com> Tested-by:
Jérôme de Bretagne <jerome.debretagne@gmail.com> Signed-off-by:
Mario Limonciello <mario.limonciello@dell.com> [dvhart: corrected commit reference format per checkpatch] Signed-off-by:
-
- 21 Jan, 2019 3 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linuxLinus Torvalds authored
Pull pstore fixes from Kees Cook: - Fix console ramoops to show the previous boot logs (Sai Prakash Ranjan) - Avoid allocation and leak of platform data * tag 'pstore-v5.0-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: pstore/ram: Avoid allocation and leak of platform data pstore/ram: Fix console ramoops to show the previous boot logs
-
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linuxLinus Torvalds authored
Pull gcc-plugins fixes from Kees Cook: "Fix ARM per-task stack protector plugin under GCC 9 (Ard Biesheuvel)" * tag 'gcc-plugins-v5.0-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: gcc-plugins: arm_ssp_per_task_plugin: fix for GCC 9+ gcc-plugins: arm_ssp_per_task_plugin: sign extend the SP mask
-
- 20 Jan, 2019 4 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/davem/netLinus Torvalds authored
Pull networking fixes from David Miller: 1) Fix endless loop in nf_tables, from Phil Sutter. 2) Fix cross namespace ip6_gre tunnel hash list corruption, from Olivier Matz. 3) Don't be too strict in phy_start_aneg() otherwise we might not allow restarting auto negotiation. From Heiner Kallweit. 4) Fix various KMSAN uninitialized value cases in tipc, from Ying Xue. 5) Memory leak in act_tunnel_key, from Davide Caratti. 6) Handle chip errata of mv88e6390 PHY, from Andrew Lunn. 7) Remove linear SKB assumption in fou/fou6, from Eric Dumazet. 8) Missing udplite rehash callbacks, from Alexey Kodanev. 9) Log dirty pages properly in vhost, from Jason Wang. 10) Use consume_skb() in neigh_probe() as this is a normal free not a drop, from Yang Wei. Likewise in macvlan_process_broadcast(). 11) Missing device_del() in mdiobus_register() error paths, from Thomas Petazzoni. 12) Fix checksum handling of short packets in mlx5, from Cong Wang. * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (96 commits) bpf: in __bpf_redirect_no_mac pull mac only if present virtio_net: bulk free tx skbs net: phy: phy driver features are mandatory isdn: avm: Fix string plus integer warning from Clang net/mlx5e: Fix cb_ident duplicate in indirect block register net/mlx5e: Fix wrong (zero) TX drop counter indication for representor net/mlx5e: Fix wrong error code return on FEC query failure net/mlx5e: Force CHECKSUM_UNNECESSARY for short ethernet frames tools: bpftool: Cleanup license mess bpf: fix inner map masking to prevent oob under speculation bpf: pull in pkt_sched.h header for tooling to fix bpftool build selftests: forwarding: Add a test case for externally learned FDB entries selftests: mlxsw: Test FDB offload indication mlxsw: spectrum_switchdev: Do not treat static FDB entries as sticky net: bridge: Mark FDB entries that were added by user as such mlxsw: spectrum_fid: Update dummy FID index mlxsw: pci: Return error on PCI reset timeout mlxsw: pci: Increase PCI SW reset timeout mlxsw: pci: Ring CQ's doorbell before RDQ's MAINTAINERS: update email addresses of liquidio driver maintainers ... -
Kees Cook authored
Yue Hu noticed that when parsing device tree the allocated platform data was never freed. Since it's not used beyond the function scope, this switches to using a stack variable instead. Reported-by:
Yue Hu <huyue2@yulong.com> Fixes: 35da6094 ("pstore/ram: add Device Tree bindings") Cc: stable@vger.kernel.org Signed-off-by:
Kees Cook <keescook@chromium.org>
-
Ard Biesheuvel authored
GCC 9 reworks the way the references to the stack canary are emitted, to prevent the value from being spilled to the stack before the final comparison in the epilogue, defeating the purpose, given that the spill slot is under control of the attacker that we are protecting ourselves from. Since our canary value address is obtained without accessing memory (as opposed to pre-v7 code that will obtain it from a literal pool), it is unlikely (although not guaranteed) that the compiler will spill the canary value in the same way, so let's just disable this improvement when building with GCC9+. Signed-off-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
-
Ard Biesheuvel authored
The ARM per-task stack protector GCC plugin hits an assert in the compiler in some case, due to the fact the the SP mask expression is not sign-extended as it should be. So fix that. Suggested-by:
Kugan Vivekanandarajah <kugan.vivekanandarajah@linaro.org> Signed-off-by:
-
