aboutsummaryrefslogtreecommitdiffstats
path: root/tools/perf/scripts/python/call-graph-from-postgresql.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2016-12-18platform/x86: Add Whiskey Cove PMIC TMU supportNilesh Bacchewar5-0/+211
This adds TMU (Time Management Unit) support for Intel BXT platform. It enables the alarm wake-up functionality in the TMU unit of Whiskey Cove PMIC. Signed-off-by: Nilesh Bacchewar <nilesh.bacchewar@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> [andy: resolve merge conflict in Kconfig] Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2016-12-16platform/x86: ideapad-laptop: Add Y700 15-ACZ to no_hw_rfkill DMI listvelemas1-0/+7
Like other Y700 models Lenovo Y700 15-ACZ does not have a physical rfkill switch. ideapad-laptop wrongly reports all radios as blocked by hardware which causes wireless network connections to fail. Add this model without an rfkill switch to the no_hw_rfkill list. Signed-off-by: Artiom Vaskov <velemas@gmail.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2016-12-16platform/x86: Introduce button support for the Surface 3Benjamin Tissoires3-0/+257
The Surface 3 is not following the ACPI spec for PNP0C40, but nearly. The device is connected to a I2C device that might have some magic but we don't know about. Just create the device after the enumeration and use the declared GPIOs to provide button support. This driver is just an adaptation of drivers/input/misc/soc_button_array.c The Surface Pro 3 is using an ACPI driver and matches against the bid of the device ("VGBI"). To prevent this incompatible driver to be used on the Surface Pro, we add a match on the Surface 3 bid "TEV2". link: https://bugzilla.kernel.org/show_bug.cgi?id=102761 Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2016-12-16platform/x86: Add custom surface3 platform device for controlling LIDBenjamin Tissoires3-0/+309
The LID state provided by ACPI on the Surface 3 is not accurate. The ACPI node doesn't get notified on LID open, which means the LID input switch stays close most of the time. Fortunatelly, there is a WMI method which directly queries the GPIO underneath the LID state, so it's far more reliable than ACPI. To get the notifications that the LID was opened/closed, we can rely on the ACPI notification of the touchscreen: the DSDT shows that the touchscreen will get notified on close/open as it also controls its _STA method. Note that we need to set the tag "power-switch" to the LID input node through a udev rule for logind to accept it: SUBSYSTEM=="input", KERNEL=="event*", KERNELS=="surface3-wmi", \ TAG+="power-switch" Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2016-12-16platform/x86: mlx-platform: Add mlxcpld-hotplug driver registrationVadim Pasternak1-1/+97
Add calls for mlxcpld-hotplug platform driver registration/unregistration and add platform hotplug data configurations. This driver, when registered within system will handle system hot-plug events for the power suppliers, power cables and fans (insertion and removing). These events are controlled through CPLD Lattice device. Signed-off-by: Vadim Pasternak <vadimp@mellanox.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2016-12-16platform/x86: mlx-platform: Fix semicolon.cocci warningskbuild test robot1-1/+1
drivers/platform/x86/mlx-platform.c:219:2-3: Unneeded semicolon Remove unneeded semicolon. Generated by: scripts/coccinelle/misc/semicolon.cocci CC: Vadim Pasternak <vadimp@mellanox.com> Signed-off-by: Fengguang Wu <fengguang.wu@intel.com> Acked-by: Vadim Pasternak <vadimp@mellanox.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2016-12-16platform/x86: mlx-platform: Move module from arch/x86Vadim Pasternak7-17/+14
Since mlx-platform is not an architectural driver, it is moved out of arch/x86/platform to drivers/platform/x86. Relevant Makefile and Kconfig are updated. Signed-off-by: Vadim Pasternak <vadimp@mellanox.com> Acked-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2016-12-15platform/x86: thinkpad_acpi: Initialize local in_tablet_mode and typeDarren Hart1-2/+2
linux-next reported in_tablet_mode and type may be used uninitialized after: b31800283868 ("platform/x86: thinkpad_acpi: Move tablet detection into separate function") This turns out to be a false positive as the pr_info call cannot be reached if tp_features.hotkey_tablet (global scope) is 0, and in_tablet_mode and type are assigned in both places tp_features.hotkey_tablet is assigned. Regardless, to make it explicit and avoid further reports, initialize in_tablet_mode to 0 and type to NULL. Signed-off-by: Darren Hart <dvhart@linux.intel.com> Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Lyude <lyude@redhat.com>
2016-12-13platform/x86: dell-laptop: Use brightness_set_blocking for kbd_led_level_setHans de Goede1-12/+14
kbd_led_level_set uses dell_smbios call which blocks, so the kbd_led classdev should use the brightness_set_blocking callback. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Pali Rohár <pali.rohar@gmail.com> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
2016-12-13platform/x86: thinkpad_acpi: Fix old style declaration GCC warningTobias Klauser1-1/+1
Fix an [-Wold-style-declaration] GCC warning by moving the inline keyword before the return type. Signed-off-by: Tobias Klauser <tklauser@distanz.ch> Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
2016-12-13platform/x86: thinkpad_acpi: Adding new hotkey ID for Lenovo thinkpadHui Wang1-0/+2
Recently we met an issue on lots of Lenovo thinkpad laptops (those laptops are not released to market yet), the issue is that the thinkpad_acpi.ko can't be automatically loaded as before. Through debugging, we found the HKEY_HID is LEN0268 instead of LEN0068 on those machines, and the MHKV is 0x200 instead of 0x100. So adding the new ID into the driver. Signed-off-by: Hui Wang <hui.wang@canonical.com> Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
2016-12-13platform/x86: thinkpad_acpi: Add support for X1 Yoga (2016) Tablet ModeLyude2-4/+36
For whatever reason, the X1 Yoga doesn't support the normal method of querying for tablet mode. Instead of providing the MHKG method under the hotkey handle, we're instead given the CMMD method under the EC handle. Values on this handle are either 0x1, laptop mode, or 0x6, tablet mode. Tested-by: Daniel Martin <consume.noise@gmail.com> Signed-off-by: Lyude <lyude@redhat.com> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
2016-12-13platform/x86: thinkpad_acpi: Move tablet detection into separate functionLyude1-15/+37
The hotkey events and ACPI handles used for detecting tablet mode on a few of the newer thinkpad models (Yoga X1 and the Yoga 260 specifically) have been changed around, so unfortunately this means we're definitely going to need to probe for multiple types of tablet mode support. Since the hotkey_init() is already a lot larger than it should be, let's split up this detection into its own function to make things a little easier to read. As well, since we're going to have multiple types of tablet modes, make hotkey_tablet into an enum so we can also use it to indicate the type of tablet mode reporting the machine supports. Suggested by Daniel Martin <consume.noise@gmail.com> Signed-off-by: Lyude <lyude@redhat.com> Cc: Daniel Martin <consume.noise@gmail.com> Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
2016-12-13platform/x86: asus-nb-wmi.c: Add X45U quirkMarcos Paulo de Souza1-0/+9
Without this patch, the Asus X45U wireless card can't be turned on (hard-blocked), but after a suspend/resume it just starts working. Following this bug report[1], there are other cases like this one, but this Asus is the only model that I can test. [1] https://ubuntuforums.org/showthread.php?t=2181558 Cc: stable@vger.kernel.org # 4.4.x- Signed-off-by: Marcos Paulo de Souza <marcos.souza.org@gmail.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2016-12-13platform/x86: asus-nb-wmi: Make use of dmi->identMarcos Paulo de Souza1-0/+1
Make use of dmi->ident as other drivers do, like fujitsu, intel, hp and samsung. Signed-off-by: Marcos Paulo de Souza <marcos.souza.org@gmail.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2016-12-13platform/x86: asus-wmi: Set specified XUSB2PR value for X550LBKai-Chuan Hsieh3-0/+43
The bluetooth adapter Atheros AR3012 can't be enumerated and make the bluetooth function broken. T: Bus=02 Lev=01 Prnt=01 Port=05 Cnt=02 Dev#= 5 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3362 Rev=00.02 S: Manufacturer=Atheros Communications S: Product=Bluetooth USB Host Controller S: SerialNumber=Alaska Day 2006 C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb The error is: usb 2-6: device not accepting address 7, error -62 usb usb2-port6: unable to enumerate USB device It is caused by adapter's connected port is mapped to xHC controller, but the xHCI is not supported by the usb device. The output of 'sudo lspci -nnxxx -s 00:14.0': 00:14.0 USB controller [0c03]: Intel Corporation 8 Series USB xHCI HC [8086:9c31] (rev 04) 00: 86 80 31 9c 06 04 90 02 04 30 03 0c 00 00 00 00 10: 04 00 a0 f7 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 1f 20 30: 00 00 00 00 70 00 00 00 00 00 00 00 0b 01 00 00 40: fd 01 36 80 89 c6 0f 80 00 00 00 00 00 00 00 00 50: 5f 2e ce 0f 00 00 00 00 00 00 00 00 00 00 00 00 60: 30 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 01 80 c2 c1 08 00 00 00 00 00 00 00 00 00 00 00 80: 05 00 87 00 0c a0 e0 fe 00 00 00 00 a1 41 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 01 04 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 0f 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 03 c0 30 00 00 00 00 00 03 0c 00 00 00 00 00 00 d0: f9 01 00 00 f9 01 00 00 0f 00 00 00 0f 00 00 00 e0: 00 08 00 00 00 00 00 00 00 00 00 00 d8 d8 00 00 f0: 00 00 00 00 00 00 00 00 b1 0f 04 08 00 00 00 00 By referencing Intel Platform Controller Hub(PCH) datasheet, the xHC USB 2.0 Port Routing(XUSB2PR) at offset 0xD0-0xD3h decides the setting of mapping the port to EHCI controller or xHC controller. And the port mapped to xHC will enable xHCI during bus resume. The setting of disabling bluetooth adapter's connected port is 0x000001D9. The value can be obtained by few times 1 bit flip operation. The suited configuration should have the 'lsusb -t' result with bluetooth using ehci: /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/9p, 480M |__ Port 5: Dev 2, If 0, Class=Video, Driver=uvcvideo, 480M |__ Port 5: Dev 2, If 1, Class=Video, Driver=uvcvideo, 480M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M |__ Port 6: Dev 3, If 0, Class=Wireless, Driver=btusb, 12M |__ Port 6: Dev 3, If 1, Class=Wireless, Driver=btusb, 12M Signed-off-by: Kai-Chuan Hsieh <kai.chiuan@gmail.com> Acked-by: Corentin Chary <corentin.chary@gmail.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> [andy: resolve merge conflict in asus-wmi.h] Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2016-12-13platform/x86: intel_mid_thermal: Fix suspend handlers unused warningBorislav Petkov1-0/+2
Fix: drivers/platform/x86/intel_mid_thermal.c:424:12: warning: ‘mid_thermal_resume’ defined but not used [-Wunused-function] static int mid_thermal_resume(struct device *dev) ^ drivers/platform/x86/intel_mid_thermal.c:436:12: warning: ‘mid_thermal_suspend’ defined but not used [-Wunused-function] static int mid_thermal_suspend(struct device *dev) ^ which I see during randbuilds here. Signed-off-by: Borislav Petkov <bp@suse.de> Cc: Darren Hart <dvhart@infradead.org> Cc: platform-driver-x86@vger.kernel.org Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2016-12-13platform/x86: intel-vbtn: Switch to use devm_input_allocate_deviceAxel Lin1-28/+5
Use devm_input_allocate_device to simplify the error handling code. This conversion also makes input_register_device() to be called after acpi_remove_notify_handler. This avoid a small window that it's possible to call notify_handler after unregister input device. Signed-off-by: Axel Lin <axel.lin@ingics.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2016-12-13platform/x86: Use ACPI_FAILURE at appropriate placesAxel Lin5-7/+7
Use ACPI_FAILURE() to replace !ACPI_SUCCESS(), this avoid !! operations. Signed-off-by: Axel Lin <axel.lin@ingics.com> Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2016-12-13platform/x86: dell-wmi: Add events created by Dell Rugged 2-in-1sMario Limonciello1-0/+10
The Dell Rugged 7202 has 3 programmable buttons (labeled P1, P2, P3) and a detachable keyboard/mouse dock. Signed-off-by: Mario Limonciello <mario_limonciello@dell.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2016-12-13platform/x86: dell-wmi: Adjust wifi catcher to emit KEY_WLANMario Limonciello1-1/+1
Wifi catcher is a slider switch, that when slid past the on position will emit an event that is intended for launching a wifi application or applet when the machine is turned on. Signed-off-by: Mario Limonciello <mario_limonciello@dell.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2016-12-13platform/x86: intel_pmc_core: Add KBL CPUID supportRajneesh Bhardwaj1-0/+4
This patch adds Kabylake CPU support for pmc_core driver. Signed-off-by: Rajneesh Bhardwaj <rajneesh.bhardwaj@intel.com> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
2016-12-13platform/x86: intel_pmc_core: Add LTR IGNORE debug featureRajneesh Bhardwaj2-1/+58
SPT LTR_IGN register provides a means to make the PMC ignore the LTR values reported by the individual PCH devices. echo <IP Offset> > /sys/kernel/debug/pmc_core/ltr_ignore. When a particular IP Offset bit is set the PMC will ignore the LTR value reported by the corresponding IP when the PMC performs the latency coalescing. IP Offset IP Name 0 SPA 1 SPB 2 SATA 3 GBE 4 XHCI 5 RSVD 6 ME 7 EVA 8 SPC 9 Azalia/ADSP 10 RSVD 11 LPSS 12 SPD 13 SPE 14 Camera 15 ESPI 16 SCC 17 ISH Signed-off-by: Rajneesh Bhardwaj <rajneesh.bhardwaj@intel.com> [dvhart: pmc_core_ltr_ignore_write local declaration order cleanup] Signed-off-by: Darren Hart <dvhart@linux.intel.com>
2016-12-13platform/x86: intel_pmc_core: Add MPHY PLL clock gating statusRajneesh Bhardwaj2-1/+69
ModPhy Common lanes can provide the clock gating status for the important system PLLs such as Gen2 USB3PCIE2 PLL, DMIPCIE3 PLL, SATA PLL and MIPI PLL. On SPT, in addition to the crystal oscillator clock, the 100Mhz Gen2 USB3PCI2 PLL clock is used as the PLL reference clock and Gen2 PLL idling is a necessary condition for the platform to go into low power states like PC10 and S0ix. Signed-off-by: Rajneesh Bhardwaj <rajneesh.bhardwaj@intel.com> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
2016-12-13platform/x86: intel_pmc_core: ModPhy core lanes pg statusRajneesh Bhardwaj2-1/+175
The PCH implements a number of High Speed I/O (HSIO) lanes that are split between PCIe*, USB 3.0, SATA, GbE, USB OTG and SSIC. This patch shows the current power gating status of the available ModPhy Core lanes. This is done by sending a message to the PMC (MTPMC) that contains the XRAM register offset for the MPHY_CORE_STS_0 and MPHY_CORE_STS_1 and then by reading the response sent by the PMC (MFPMC). While enabling low power modes we often encounter situations when the ModPhy lanes are not power gated and it becomes hard to debug which lane is active and which is not in the absence of an external hardware debugger (JTAG/ITP). This patch eliminates the dependency on an external hardware debugger for reading the ModPhy Lanes power gating status. This patch requires PMC_READ_DISABLE setting to be disabled in the platform bios. cat /sys/kernel/debug/pmc_core/mphy_lanes_power_gating_status Signed-off-by: Rajneesh Bhardwaj <rajneesh.bhardwaj@intel.com> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
2016-12-13platform/x86: intel_pmc_core: Add PCH IP Power Gating StatusRajneesh Bhardwaj2-5/+184
This patch adds the support for reading the power gating status of various devices present on Sunrise Point PCH. This is intended to be used for debugging purpose while tuning the platform for power optimizations and also to understand which devices (on PCH) are blocking the system to enter a low power state. Power Management Controller on Sunrise Point PCH provides access to "PGD PFET Enable Ack Status Registers (ppfear)". This patch reads and decodes this register and dumps the output in formatted manner showing various devices present on the PCH and their "Power Gating" status. Further documentation can be found in Intel 7th Gen Core family mobile u/y processor io datasheet volume 2. Sample output (stripped and not in order): cat /sys/kernel/debug/pmc_core/pch_ip_power_gating_status PMC State: Not Power gated OPI-DMI State: Not Power gated XHCI State: Power gated LPSS State: Power gated CSME_PSF State: Not power gated Signed-off-by: Rajneesh Bhardwaj <rajneesh.bhardwaj@intel.com> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
2016-12-13platform/x86: intel_pmc_core: Fix PWRMBASE mask and mmio reg lenRajneesh Bhardwaj2-1/+3
On Sunrise Point PCH, the Power Management Controller provides 4K bytes of memory space for various power management and debug registers. This fix is needed to access power management & debug registers that are mapped at a higher offset. Also, this provides a fix for correctly masking the PWRMBASE as the initial bits (0-11) are reserved. Signed-off-by: Rajneesh Bhardwaj <rajneesh.bhardwaj@intel.com> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
2016-12-13platform/x86: acer-wmi: Only supports AMW0_GUID1 on acer familyLee, Chun-Yi1-0/+56
The AMW0_GUID1 wmi is not only found on Acer family but also other machines like Lenovo, Fujitsu and Medion. In the past, acer-wmi handled those non-Acer machines by quirks list. But actually acer-wmi driver was loaded on any machine that had AMW0_GUID1. This behavior is strange because those machines should be supported by appropriate wmi drivers. e.g. fujitsu-laptop, ideapad-laptop. This patch adds the logic to check the machine that has AMW0_GUID1 should be in Acer/Packard Bell/Gateway white list. But, it still keeps the quirk list of those supported non-acer machines for backward compatibility. Tested-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Lee, Chun-Yi <jlee@suse.com> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
2016-10-23platform/x86: Introduce support for Mellanox hotplug driverVadim Pasternak5-0/+633
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: Vadim Pasternak <vadimp@mellanox.com> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
2016-10-19printk: suppress empty continuation linesLinus Torvalds1-0/+4
We have a fairly common pattern where you print several things as continuations on one single line in a loop, and then at the end you do printk(KERN_CONT "\n"); to flush the buffered output. But if the output was flushed by something else (concurrent printk activity, or just system logging), we don't want that final flushing to just print an empty line. So just suppress empty continuation lines when they couldn't be merged into the line they are a continuation of. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-10-19mm: replace access_process_vm() write parameter with gup_flagsLorenzo Stoakes17-54/+84
This removes the 'write' argument from access_process_vm() and replaces it with 'gup_flags' as use of this function previously silently implied FOLL_FORCE, whereas after this patch callers explicitly pass this flag. We make this explicit as use of FOLL_FORCE can result in surprising behaviour (and hence bugs) within the mm subsystem. Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com> Acked-by: Jesper Nilsson <jesper.nilsson@axis.com> Acked-by: Michal Hocko <mhocko@suse.com> Acked-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-10-19mm: replace access_remote_vm() write parameter with gup_flagsLorenzo Stoakes4-19/+20
This removes the 'write' argument from access_remote_vm() and replaces it with 'gup_flags' as use of this function previously silently implied FOLL_FORCE, whereas after this patch callers explicitly pass this flag. We make this explicit as use of FOLL_FORCE can result in surprising behaviour (and hence bugs) within the mm subsystem. Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com> Acked-by: Michal Hocko <mhocko@suse.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-10-19mm: replace __access_remote_vm() write parameter with gup_flagsLorenzo Stoakes2-11/+21
This removes the 'write' argument from __access_remote_vm() and replaces it with 'gup_flags' as use of this function previously silently implied FOLL_FORCE, whereas after this patch callers explicitly pass this flag. We make this explicit as use of FOLL_FORCE can result in surprising behaviour (and hence bugs) within the mm subsystem. Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com> Acked-by: Michal Hocko <mhocko@suse.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-10-19mm: replace get_user_pages_remote() write/force parameters with gup_flagsLorenzo Stoakes9-27/+40
This removes the 'write' and 'force' from get_user_pages_remote() and replaces them with 'gup_flags' to make the use of FOLL_FORCE explicit in callers as use of this flag can result in surprising behaviour (and hence bugs) within the mm subsystem. Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com> Acked-by: Michal Hocko <mhocko@suse.com> Reviewed-by: Jan Kara <jack@suse.cz> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-10-19mm: replace get_user_pages() write/force parameters with gup_flagsLorenzo Stoakes22-54/+49
This removes the 'write' and 'force' from get_user_pages() and replaces them with 'gup_flags' to make the use of FOLL_FORCE explicit in callers as use of this flag can result in surprising behaviour (and hence bugs) within the mm subsystem. Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com> Acked-by: Christian König <christian.koenig@amd.com> Acked-by: Jesper Nilsson <jesper.nilsson@axis.com> Acked-by: Michal Hocko <mhocko@suse.com> Reviewed-by: Jan Kara <jack@suse.cz> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-10-19mm: replace get_vaddr_frames() write/force parameters with gup_flagsLorenzo Stoakes5-15/+11
This removes the 'write' and 'force' from get_vaddr_frames() and replaces them with 'gup_flags' to make the use of FOLL_FORCE explicit in callers as use of this flag can result in surprising behaviour (and hence bugs) within the mm subsystem. Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com> Acked-by: Michal Hocko <mhocko@suse.com> Reviewed-by: Jan Kara <jack@suse.cz> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-10-19mm: replace get_user_pages_locked() write/force parameters with gup_flagsLorenzo Stoakes4-12/+15
This removes the 'write' and 'force' use from get_user_pages_locked() and replaces them with 'gup_flags' to make the use of FOLL_FORCE explicit in callers as use of this flag can result in surprising behaviour (and hence bugs) within the mm subsystem. Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com> Acked-by: Michal Hocko <mhocko@suse.com> Reviewed-by: Jan Kara <jack@suse.cz> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-10-19sched/fair: Fix incorrect task group ->load_avgVincent Guittot1-1/+8
A scheduler performance regression has been reported by Joseph Salisbury, which he bisected back to: 3d30544f0212 ("sched/fair: Apply more PELT fixes) The regression triggers when several levels of task groups are involved (read: SystemD) and cpu_possible_mask != cpu_present_mask. The root cause is that group entity's load (tg_child->se[i]->avg.load_avg) is initialized to scale_load_down(se->load.weight). During the creation of a child task group, its group entities on possible CPUs are attached to parent's cfs_rq (tg_parent) and their loads are added to the parent's load (tg_parent->load_avg) with update_tg_load_avg(). But only the load on online CPUs will then be updated to reflect real load, whereas load on other CPUs will stay at the initial value. The result is a tg_parent->load_avg that is higher than the real load, the weight of group entities (tg_parent->se[i]->load.weight) on online CPUs is smaller than it should be, and the task group gets a less running time than what it could expect. ( This situation can be detected with /proc/sched_debug. The ".tg_load_avg" of the task group will be much higher than sum of ".tg_load_avg_contrib" of online cfs_rqs of the task group. ) The load of group entities don't have to be intialized to something else than 0 because their load will increase when an entity is attached. Reported-by: Joseph Salisbury <joseph.salisbury@canonical.com> Tested-by: Dietmar Eggemann <dietmar.eggemann@arm.com> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org> Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: <stable@vger.kernel.org> # 4.8.x Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: joonwoop@codeaurora.org Fixes: 3d30544f0212 ("sched/fair: Apply more PELT fixes) Link: http://lkml.kernel.org/r/1476881123-10159-1-git-send-email-vincent.guittot@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-10-18sh: add earlycon support to j2_defconfigRich Felker1-0/+1
Signed-off-by: Rich Felker <dalias@libc.org>
2016-10-18sh: add Kconfig option for J-Core SoC core driversRich Felker2-0/+11
Signed-off-by: Rich Felker <dalias@libc.org>
2016-10-18mm: replace get_user_pages_unlocked() write/force parameters with gup_flagsLorenzo Stoakes14-36/+27
This removes the 'write' and 'force' use from get_user_pages_unlocked() and replaces them with 'gup_flags' to make the use of FOLL_FORCE explicit in callers as use of this flag can result in surprising behaviour (and hence bugs) within the mm subsystem. Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com> Reviewed-by: Jan Kara <jack@suse.cz> Acked-by: Michal Hocko <mhocko@suse.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-10-18mm: remove write/force parameters from __get_user_pages_unlocked()Lorenzo Stoakes6-19/+34
This removes the redundant 'write' and 'force' parameters from __get_user_pages_unlocked() to make the use of FOLL_FORCE explicit in callers as use of this flag can result in surprising behaviour (and hence bugs) within the mm subsystem. Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Jan Kara <jack@suse.cz> Acked-by: Michal Hocko <mhocko@suse.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-10-18mm: remove write/force parameters from __get_user_pages_locked()Lorenzo Stoakes1-14/+33
This removes the redundant 'write' and 'force' parameters from __get_user_pages_locked() to make the use of FOLL_FORCE explicit in callers as use of this flag can result in surprising behaviour (and hence bugs) within the mm subsystem. Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com> Reviewed-by: Jan Kara <jack@suse.cz> Acked-by: Michal Hocko <mhocko@suse.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-10-18mm: remove gup_flags FOLL_WRITE games from __get_user_pages()Linus Torvalds2-2/+13
This is an ancient bug that was actually attempted to be fixed once (badly) by me eleven years ago in commit 4ceb5db9757a ("Fix get_user_pages() race for write access") but that was then undone due to problems on s390 by commit f33ea7f404e5 ("fix get_user_pages bug"). In the meantime, the s390 situation has long been fixed, and we can now fix it by checking the pte_dirty() bit properly (and do it better). The s390 dirty bit was implemented in abf09bed3cce ("s390/mm: implement software dirty bits") which made it into v3.9. Earlier kernels will have to look at the page state itself. Also, the VM has become more scalable, and what used a purely theoretical race back then has become easier to trigger. To fix it, we introduce a new internal FOLL_COW flag to mark the "yes, we already did a COW" rather than play racy games with FOLL_WRITE that is very fundamental, and then use the pte dirty flag to validate that the FOLL_COW flag is still valid. Reported-and-tested-by: Phil "not Paul" Oester <kernel@linuxace.com> Acked-by: Hugh Dickins <hughd@google.com> Reviewed-by: Michal Hocko <mhocko@suse.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Kees Cook <keescook@chromium.org> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Willy Tarreau <w@1wt.eu> Cc: Nick Piggin <npiggin@gmail.com> Cc: Greg Thelen <gthelen@google.com> Cc: stable@vger.kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-10-18pinctrl: intel: Only restore pins that are used by the driverMika Westerberg1-2/+23
Dell XPS 13 (and maybe some others) uses a GPIO (CPU_GP_1) during suspend to explicitly disable USB touchscreen interrupt. This is done to prevent situation where the lid is closed the touchscreen is left functional. The pinctrl driver (wrongly) assumes it owns all pins which are owned by host and not locked down. It is perfectly fine for BIOS to use those pins as it is also considered as host in this context. What happens is that when the lid of Dell XPS 13 is closed, the BIOS configures CPU_GP_1 low disabling the touchscreen interrupt. During resume we restore all host owned pins to the known state which includes CPU_GP_1 and this overwrites what the BIOS has programmed there causing the touchscreen to fail as no interrupts are reaching the CPU anymore. Fix this by restoring only those pins we know are explicitly requested by the kernel one way or other. Cc: stable@vger.kernel.org Link: https://bugzilla.kernel.org/show_bug.cgi?id=176361 Reported-by: AceLan Kao <acelan.kao@canonical.com> Tested-by: AceLan Kao <acelan.kao@canonical.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-10-18pinctrl: baytrail: Fix lockdepVille Syrjälä1-1/+2
Initialize the spinlock before using it. INFO: trying to register non-static key. the code is fine but needs lockdep annotation. turning off the locking correctness validator. CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.8.0-dwc-bisect #4 Hardware name: Intel Corp. VALLEYVIEW C0 PLATFORM/BYT-T FFD8, BIOS BLAKFF81.X64.0088.R10.1403240443 FFD8_X64_R_2014_13_1_00 03/24/2014 0000000000000000 ffff8800788ff770 ffffffff8133d597 0000000000000000 0000000000000000 ffff8800788ff7e0 ffffffff810cfb9e 0000000000000002 ffff8800788ff7d0 ffffffff8205b600 0000000000000002 ffff8800788ff7f0 Call Trace: [<ffffffff8133d597>] dump_stack+0x67/0x90 [<ffffffff810cfb9e>] register_lock_class+0x52e/0x540 [<ffffffff810d2081>] __lock_acquire+0x81/0x16b0 [<ffffffff810cede1>] ? save_trace+0x41/0xd0 [<ffffffff810d33b2>] ? __lock_acquire+0x13b2/0x16b0 [<ffffffff810cf05a>] ? __lock_is_held+0x4a/0x70 [<ffffffff810d3b1a>] lock_acquire+0xba/0x220 [<ffffffff8136f1fe>] ? byt_gpio_get_direction+0x3e/0x80 [<ffffffff81631567>] _raw_spin_lock_irqsave+0x47/0x60 [<ffffffff8136f1fe>] ? byt_gpio_get_direction+0x3e/0x80 [<ffffffff8136f1fe>] byt_gpio_get_direction+0x3e/0x80 [<ffffffff813740a9>] gpiochip_add_data+0x319/0x7d0 [<ffffffff81631723>] ? _raw_spin_unlock_irqrestore+0x43/0x70 [<ffffffff8136fe3b>] byt_pinctrl_probe+0x2fb/0x620 [<ffffffff8142fb0c>] platform_drv_probe+0x3c/0xa0 ... Based on the diff it looks like the problem was introduced in commit 71e6ca61e826 ("pinctrl: baytrail: Register pin control handling") but I wasn't able to verify that empirically as the parent commit just oopsed when I tried to boot it. Cc: Cristina Ciocan <cristina.ciocan@intel.com> Cc: stable@vger.kernel.org Fixes: 71e6ca61e826 ("pinctrl: baytrail: Register pin control handling") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-10-18pinctrl: aspeed-g5: Fix pin association of SPI1 functionAndrew Jeffery2-9/+81
The SPI1 function was associated with the wrong pins: The functions that those pins provide is either an SPI debug or passthrough function coupled to SPI1. Make the SPI1 mux function configure the relevant pins and associate new SPI1DEBUG and SPI1PASSTHRU functions with the pins that were already defined. The notation used in the datasheet's multi-function pin table for the SoC is often creative: in this case the SYS* signals are enabled by a single bit, which is nothing unusual on its own, but in this case the bit was also participating in a multi-bit bitfield and therefore represented multiple functions. This fact was overlooked in the original patch. Fixes: 56e57cb6c07f (pinctrl: Add pinctrl-aspeed-g5 driver) Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Reviewed-by: Joel Stanley <joel@jms.id.au> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-10-18pinctrl: aspeed-g5: Fix GPIOE1 typoAndrew Jeffery1-1/+1
This prevented C20 from successfully being muxed as GPIO. Fixes: 56e57cb6c07f (pinctrl: Add pinctrl-aspeed-g5 driver) Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Reviewed-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-10-18pinctrl: aspeed-g5: Fix names of GPID2 pinsAndrew Jeffery1-6/+6
Fixes simple typos in the initial commit. There is no behavioural change. Fixes: 56e57cb6c07f (pinctrl: Add pinctrl-aspeed-g5 driver) Reported-by: Xo Wang <xow@google.com> Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Reviewed-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-10-18pinctrl: aspeed: "Not enabled" is a significant mux stateAndrew Jeffery1-5/+7
Consider a scenario with one pin P that has two signals A and B, where A is defined to be higher priority than B: That is, if the mux IP is in a state that would consider both A and B to be active on P, then A will be the active signal. To instead configure B as the active signal we must configure the mux so that A is inactive. The mux state for signals can be described by logical operations on one or more bits from one or more registers (a "signal expression"), which in some cases leads to aliased mux states for a particular signal. Further, signals described by multi-bit bitfields often do not only need to record the states that would make them active (the "enable" expressions), but also the states that makes them inactive (the "disable" expressions). All of this combined leads to four possible states for a signal: 1. A signal is active with respect to an "enable" expression 2. A signal is not active with respect to an "enable" expression 3. A signal is inactive with respect to a "disable" expression 4. A signal is not inactive with respect to a "disable" expression In the case of P, if we are looking to activate B without explicitly having configured A it's enough to consider A inactive if all of A's "enable" signal expressions evaluate to "not active". If any evaluate to "active" then the corresponding "disable" states must be applied so it becomes inactive. For example, on the AST2400 the pins composing GPIO bank H provide signals ROMD8 through ROMD15 (high priority) and those for UART6 (low priority). The mux states for ROMD8 through ROMD15 are aliased, i.e. there are two mux states that result in the respective signals being configured: A. SCU90[6]=1 B. Strap[4,1:0]=100 Further, the second mux state is a 3-bit bitfield that explicitly defines the enabled state but the disabled state is implicit, i.e. if Strap[4,1:0] is not exactly "100" then ROMD8 through ROMD15 are not considered active. This requires the mux function evaluation logic to use approach 2. above, however the existing code was using approach 3. The problem was brought to light on the Palmetto machines where the strap register value is 0x120ce416, and prevented GPIO requests in bank H from succeeding despite the hardware being in a position to allow them. Fixes: 318398c09a8d ("pinctrl: Add core pinctrl support for Aspeed SoCs") Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Reviewed-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>