summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* dell-laptop: Update information about wireless controlPali Rohár2015-06-221-39/+119
| | | | | | | | Make sure that all existing SMBIOS calls for wireless control are properly documented. This commit also add new documentation released by Dell. Signed-off-by: Pali Rohár <pali.rohar@gmail.com> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
* MAINTAINERS: Orphan x86 driver msi-wmiAnisse Astier2015-06-151-2/+1
| | | | | | | | I haven't touched the code in a long time, and I don't have access to the hardware anymore to test any changes to this driver. Signed-off-by: Anisse Astier <anisse@astier.eu> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
* ideapad: fix software rfkill settingArnd Bergmann2015-06-151-1/+2
| | | | | | | | | | | | | | | | This fixes a several year old regression that I found while trying to get the Yoga 3 11 to work. The ideapad_rfk_set function is meant to send a command to the embedded controller through ACPI, but as of c1f73658ed, it sends the index of the rfkill device instead of the command, and ignores the opcode field. This changes it back to the original behavior, which indeed flips the rfkill state as seen in the debugfs interface. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: c1f73658ed ("ideapad: pass ideapad_priv as argument (part 2)") Cc: stable@vger.kernel.org # v2.6.38+ Signed-off-by: Darren Hart <dvhart@linux.intel.com>
* dell-laptop: Use dell-rbtn instead i8042 filter when possiblePali Rohár2015-06-111-8/+86
| | | | | | | | | | | | | | | | | | | | | Until now module dell-laptop registered rfkill device which used i8042 filter function for receiving HW switch rfkill events (handling special keycode). But for some dell laptops there is native ACPI driver dell-rbtn which can receive rfkill events (without i8042 hooks). So this patch will combine best from both sides. It will use native ACPI driver dell-rbtn for receiving events and dell-laptop SMBIOS interface for enabling or disabling radio devices. If ACPI driver or device will not be available fallback to i8042 filter function will be used. Patch also changes module_init() to late_initcall() to ensure that init function will be called after initializing dell-rbtn.c driver. Signed-off-by: Pali Rohár <pali.rohar@gmail.com> Tested-by: Gabriele Mazzotta <gabriele.mzt@gmail.com> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
* dell-rbtn: Export notifier for other kernel modulesPali Rohár2015-06-112-1/+116
| | | | | | | | | | | | | | | This patch exports notifier functions so other modules can receive HW switch events. By default when some module register notifier, dell-rbtn driver automatically remove rfkill interfaces from system (it is expected that other module will use events for other rfkill interface). This behaviour can be changed with new module parameter "auto_remove_rfkill". This patch is designed for dell-laptop module for receiving those events. Signed-off-by: Pali Rohár <pali.rohar@gmail.com> Tested-by: Gabriele Mazzotta <gabriele.mzt@gmail.com> [dvhart@linux.intel.com: Cleanup MODULE_PARM_DESC formatting and grammar] Signed-off-by: Darren Hart <dvhart@linux.intel.com>
* dell-rbtn: Dell Airplane Mode Switch driverPali Rohár2015-06-114-0/+354
| | | | | | | | | | | | | | | | This is an ACPI driver for Dell laptops which receive HW slider radio switch or hotkey toggle wifi button events. It exports rfkill device dell-rbtn (which provide correct hard rfkill state) or hotkey input device. Alex Hung is author of original hotkey input device code. Signed-off-by: Pali Rohár <pali.rohar@gmail.com> Tested-by: Gabriele Mazzotta <gabriele.mzt@gmail.com> Cc: Alex Hung <alex.hung@canonical.com> [fengguang.wu@intel.com: rbtn_ops can be static] Signed-off-by: Fengguang Wu <fengguang.wu@intel.com> [dvhart@linux.intel.com: Correct multi-line comment formatting] Signed-off-by: Darren Hart <dvhart@linux.intel.com>
* samsung-laptop: Use acpi_video_unregister_backlight instead of ↵Hans de Goede2015-06-081-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | acpi_video_unregister acpi_video_unregister() not only unregisters the acpi-video backlight interface but also unregisters the acpi video bus event listener, causing e.g. brightness hotkey presses to no longer generate keypress events. The unregistering of the acpi video bus event listener usually is undesirable, which by itself is a good reason to switch to acpi_video_unregister_backlight(). Another problem with using acpi_video_unregister() rather then using acpi_video_unregister_backlight() is that on systems with an intel video opregion (most systems) and a broken_acpi_video quirk, whether or not the acpi video bus event listener actually gets unregistered depends on module load ordering: Scenario a: 1) acpi/video.ko gets loaded (*), does not do acpi_video_register as there is an intel opregion. 2) intel.ko gets loaded, calls acpi_video_register() which registers both the listener and the acpi backlight interface 3) samsung-laptop.ko gets loaded, calls acpi_video_unregister() causing both the listener and the acpi backlight interface to unregister Scenario b: 1) acpi/video.ko gets loaded (*), does not do acpi_video_register as there is an intel opregion. 2) samsung-laptop.ko gets loaded, calls acpi_video_dmi_promote_vendor(), calls acpi_video_unregister(), which is a nop since acpi_video_register has not yet been called 2) intel.ko gets loaded, calls acpi_video_register() which registers the listener, but does not register the acpi backlight interface due to the call to the preciding call to acpi_video_dmi_promote_vendor() *) acpi/video.ko always loads first as both other modules depend on it. So we end up with or without an acpi video bus event listener depending on module load ordering, not good. Switching to using acpi_video_unregister_backlight() means that independ of ordering we will always have an acpi video bus event listener fixing this. Note that this commit means that systems without an intel video opregion, and systems which were hitting scenario a wrt module load ordering, are now getting an acpi video bus event listener while before they were not! On some systems this may cause the brightness hotkeys to start generating keypresses while before they were not (good), while on other systems this may cause the brightness hotkeys to generate multiple keypress events for a single press (not so good). Since on most systems the acpi video bus is the canonical source for brightness events I believe that the latter case will needs to be handled on a case by case basis by filtering out the duplicate keypresses at the other source for them. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Corentin Chary <corentin.chary@gmail.com) Signed-off-by: Darren Hart <dvhart@linux.intel.com>
* asus-wmi: Use acpi_video_unregister_backlight instead of acpi_video_unregisterHans de Goede2015-06-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | acpi_video_unregister() not only unregisters the acpi-video backlight interface but also unregisters the acpi video bus event listener, causing e.g. brightness hotkey presses to no longer generate keypress events. The unregistering of the acpi video bus event listener usually is undesirable, which by itself is a good reason to switch to acpi_video_unregister_backlight(). Another problem with using acpi_video_unregister() rather then using acpi_video_unregister_backlight() is that on systems with an intel video opregion (most systems) and a wmi_backlight_power quirk, whether or not the acpi video bus event listener actually gets unregistered depends on module load ordering: Scenario a: 1) acpi/video.ko gets loaded (*), does not do acpi_video_register as there is an intel opregion. 2) intel.ko gets loaded, calls acpi_video_register() which registers both the listener and the acpi backlight interface 3) asus-wmi.ko gets loaded, calls acpi_video_unregister() causing both the listener and the acpi backlight interface to unregister Scenario b: 1) acpi/video.ko gets loaded (*), does not do acpi_video_register as there is an intel opregion. 2) asus-wmi.ko gets loaded, calls acpi_video_dmi_promote_vendor(), calls acpi_video_unregister(), which is a nop since acpi_video_register has not yet been called 2) intel.ko gets loaded, calls acpi_video_register() which registers the listener, but does not register the acpi backlight interface due to the call to the preciding call to acpi_video_dmi_promote_vendor() *) acpi/video.ko always loads first as both other modules depend on it. So we end up with or without an acpi video bus event listener depending on module load ordering, not good. Switching to using acpi_video_unregister_backlight() means that independ of ordering we will always have an acpi video bus event listener fixing this. Note that this commit means that systems without an intel video opregion, and systems which were hitting scenario a wrt module load ordering, are now getting an acpi video bus event listener while before they were not! On some systems this may cause the brightness hotkeys to start generating keypresses while before they were not (good), while on other systems this may cause the brightness hotkeys to generate multiple keypress events for a single press (not so good). Since on most systems the acpi video bus is the canonical source for brightness events I believe that the latter case will needs to be handled on a case by case basis by filtering out the duplicate keypresses at the other source for them. Cc: acpi4asus-user@lists.sourceforge.net Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Corentin Chary <corentin.chary@gmail.com) Signed-off-by: Darren Hart <dvhart@linux.intel.com>
* apple_gmux: Use acpi_video_unregister_backlight instead of acpi_video_unregisterHans de Goede2015-06-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | acpi_video_unregister() not only unregisters the acpi-video backlight interface but also unregisters the acpi video bus event listener, causing e.g. brightness hotkey presses to no longer generate keypress events. The unregistering of the acpi video bus event listener usually is undesirable, which by itself is a good reason to switch to acpi_video_unregister_backlight(). Another problem with using acpi_video_unregister() rather then using acpi_video_unregister_backlight() is that on systems with an intel video opregion (most systems) whether or not the acpi video bus event listener actually gets unregistered depends on module load ordering: Scenario a: 1) acpi/video.ko gets loaded (*), does not do acpi_video_register as there is an intel opregion. 2) intel.ko gets loaded, calls acpi_video_register() which registers both the listener and the acpi backlight interface 3) apple-gmux.ko gets loaded, calls acpi_video_unregister() causing both the listener and the acpi backlight interface to unregister Scenario b: 1) acpi/video.ko gets loaded (*), does not do acpi_video_register as there is an intel opregion. 2) apple-gmux.ko gets loaded, calls acpi_video_dmi_promote_vendor(), calls acpi_video_unregister(), which is a nop since acpi_video_register has not yet been called 2) intel.ko gets loaded, calls acpi_video_register() which registers the listener, but does not register the acpi backlight interface due to the call to the preciding call to acpi_video_dmi_promote_vendor() *) acpi/video.ko always loads first as both other modules depend on it. So we end up with or without an acpi video bus event listener depending on module load ordering, not good. Switching to using acpi_video_unregister_backlight() means that independ of ordering we will always have an acpi video bus event listener fixing this. Note that this commit means that systems without an intel video opregion, and systems which were hitting scenario a wrt module load ordering, are now getting an acpi video bus event listener while before they were not! On some systems this may cause the brightness hotkeys to start generating keypresses while before they were not (good), while on other systems this may cause the brightness hotkeys to generate multiple keypress events for a single press (not so good). Since on most systems the acpi video bus is the canonical source for brightness events I believe that the latter case will needs to be handled on a case by case basis by filtering out the duplicate keypresses at the other source for them. Cc: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
* pvpanic: handle missing _STA correctlyRadim Krčmář2015-06-081-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | pvpanic was not properly detected when _STA was missing. ACPI 6.0 April 2015, 6.3.7 _STA (Status) If a device object (including the processor object) does not have an _STA object, then OSPM assumes that all of the above bits are set (i.e., the device is present, enabled, shown in the UI, and functioning). Not adhering to the specification made pvpanic dormant under QEMU 2.3. The original patch used acpi_bus_get_status_handle, which was not being exported, so module build blew up; switch to acpi_bus_get_status and use the status it populates. Populated status is a bitfield so we can make the code self-documenting. We do not check 'present' because 'enabled' has to be false in that case by specification. Older QEMUs set 0xff to status and newer ones do 0xb. Suggested-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Radim Krčmář <rkrcmar@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> [dvhart@linux.intel.com: Merge acpi_bug_get_status fix to avoid bisect breakage] Signed-off-by: Darren Hart <dvhart@linux.intel.com>
* ideapad_laptop: Lenovo G50-30 fix rfkill reports wireless blockedDmitry Tunin2015-06-011-0/+7
| | | | | | | | | | | | Lenovo G30-50 does not have a hardware wireless switch and wireless is always blocked. BugLink: https://bugs.launchpad.net/bugs/1397021 Signed-off-by: Dmitry Tunin <hanipouspilot@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Philippe Coval <philippe.coval@open.eurogiciel.org> [dvhart@linux.intel.com: Reordered dmi id per Phillippe's later version] Signed-off-by: Darren Hart <dvhart@linux.intel.com>
* asus-wmi: add fan controlKast Bernd2015-05-131-21/+323
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch is partially based on Felipe Contrera's earlier patch, that was discussed here: https://lkml.org/lkml/2013/10/8/800 Some problems of that patch are solved, now: 1) The main obstacle for the earlier patch seemed to be the use of virt_to_phys, which is accepted, now 2) random memory corruption occurred on my notebook, thus DMA-able memory is allocated now, which solves this problem 3) hwmon interface is used instead of the thermal interface, as a hwmon device is already set up by this driver and seemed more appropriate than the thermal interface 4) Calling the ACPI-functions was modularized thus it's possible to call some multifunctions easily, now (by using asus_wmi_evaluate_method_agfn). Unfortunately the WMI doesn't support controlling both fans on a dual-fan notebook because of an restriction in the acpi-method "SFNS", that is callable through the wmi. If "SFNV" would be called directly even dual fan configurations could be controlled, but not by using wmi. Speed readings only work on auto-mode, thus "-1" will be reported in manual mode. Additionally the speed readings are reported as hundreds of RPM thus they are not too precise. This patch is tested only on one notebook (N551JK) but a similar module, that contained some code to try to control the second fan also, was reported to work on an UX32VD, at least for the first fan. As Felipe already mentioned the low-level functions are described here: http://forum.notebookreview.com/threads/fan-control-on-asus-prime-ux31-ux31a-ux32a-ux32vd.705656/ Signed-off-by: Kast Bernd <kastbernd@gmx.de> Acked-by: Corentin Chary <corentin.chary@gmail.com> Cc: Corentin Chary <corentin.chary@gmail.com> Cc: Darren Hart <dvhart@infradead.org> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Rafael J. Wysocki <rjw@rjwysocki.net> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
* Documentation/ABI: Add file describing the sysfs entries for toshiba_hapsAzael Avalos2015-05-111-0/+20
| | | | | | | | This patch adds a new file describing the sysfs entries for the toshiba_haps driver. Signed-off-by: Azael Avalos <coproscefalo@gmail.com> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
* toshiba_haps: Make use of DEVICE_ATTR_{RW, WO} macrosAzael Avalos2015-05-111-4/+2
| | | | | | | | This patch makes use of DEVICE_ATTR_{RW, WO} macros, simplifying device attributes creation. Signed-off-by: Azael Avalos <coproscefalo@gmail.com> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
* toshiba_haps: Replace sscanf with kstrtointAzael Avalos2015-05-111-8/+18
| | | | | | | | This patch simply replaces the use of sscanf with kstrtoint returning the error code in case that something went bad. Signed-off-by: Azael Avalos <coproscefalo@gmail.com> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
* toshiba_acpi: Bump driver version to 0.22Azael Avalos2015-05-111-1/+1
| | | | | | | | | This patch simply bumps the driver version to 0.22, as significant changes were made to the driver, such as cleanups, updated events, keymap handling, fixes and the bluetooth rfkill code removal. Signed-off-by: Azael Avalos <coproscefalo@gmail.com> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
* toshiba_acpi: Remove TOS_FAILURE check from some functionsAzael Avalos2015-05-111-10/+10
| | | | | | | | | | This patch removes the check for TOS_FAILURE whenever we are using the tci_raw function call, as that code is only returned by the {hci, sci}_{read, write} functions and never by the tci_raw, and thus making that check irrelevant. Signed-off-by: Azael Avalos <coproscefalo@gmail.com> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
* toshiba_acpi: Comments cleanupAzael Avalos2015-05-111-7/+10
| | | | | | | | | | This patch simply does some misc cleanup to comments, mainly capitalizes some left over comments from a previous clean up and adds some comments at the beginning of some feature function calls, as well as some misc changes to some comments. Signed-off-by: Azael Avalos <coproscefalo@gmail.com> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
* toshiba_acpi: Rename hci_{read, write}1 functionsAzael Avalos2015-05-111-22/+22
| | | | | | | | This patch simply renames the hci_{read, write}1 functions to hci_{read, write}. Signed-off-by: Azael Avalos <coproscefalo@gmail.com> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
* toshiba_acpi: Remove no longer needed hci_{read, write}2 functionsAzael Avalos2015-05-111-32/+7
| | | | | | | | | | | | | | This patch removes the hci_{read, write}2 functions from the driver, and the toshiba_hotkey_event_type_get function was adapted to use the tci_raw function. The hci_write2 function was only used by the bluetooth rfkill code, but since its removal, it was causing build warnings, and the hci_read2 function was only used by the toshiba_hotkey_event_type_get function. Signed-off-by: Azael Avalos <coproscefalo@gmail.com> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
* toshiba_bluetooth: Change BT status message to debugAzael Avalos2015-05-111-2/+3
| | | | | | | | | | | | | | | The function toshiba_bluetooth_status is currently printing the status of the device whenever it is queried, but since the introduction of the rfkill poll code, this value will get printed everytime the poll occurs. This patch removes the status message from the *_status function, and adds a debug message to the *_sync_status function printing the bluetooth device raw status, killswitch, plug and power states of the device as well. Signed-off-by: Azael Avalos <coproscefalo@gmail.com> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
* toshiba_bluetooth: Adapt *_enable, *_notify and *_resume functions to rfkillAzael Avalos2015-05-071-29/+18
| | | | | | | | | | | | This patch adapts toshiba_bluetooth_enable, toshiba_bt_rfkill_notify and toshiba_bt_resume functions to rfkill. The *_enable function was cleaned from code that the rfkill code now provides, and the other two functions were modified to update the rfkill switch status, as they were only calling toshiba_bluetooth_enable. Signed-off-by: Azael Avalos <coproscefalo@gmail.com> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
* toshiba_bluetooth: Add RFKill handler functionsAzael Avalos2015-05-072-9/+69
| | | | | | | | | | | This patch adds RFKill handler functions to the driver, allowing it to register and update the rfkill switch status. Also, a comment block was moved from the header to the poll function, as it explains why we need to poll the killswitch on older devices. Signed-off-by: Azael Avalos <coproscefalo@gmail.com> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
* toshiba_bluetooth: Add a container struct named toshiba_bluetooth_devAzael Avalos2015-05-071-1/+46
| | | | | | | | | | | | | | This patch adds a struct named toshiba_bluetooth_dev, which will be used to contain the acpi_device struct and bluetooth status booleans. This struct will also be used by later patches to store the rfkill struct as well. Also, a helper function named toshiba_bluetooth_sync_status was added to be also used by upcomming patches. Signed-off-by: Azael Avalos <coproscefalo@gmail.com> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
* toshiba_acpi: Remove bluetooth rfkill codeAzael Avalos2015-05-072-125/+0
| | | | | | | | | | | This patch removes all bluetooth rfkill related code residing in the toshiba_acpi driver. Separate patches will add (and adapt) the code to toshiba_bluetooth (where it belongs). Signed-off-by: Azael Avalos <coproscefalo@gmail.com> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
* Linux 4.1-rc1v4.1-rc1Linus Torvalds2015-04-271-2/+2
|
* x86_64, asm: Work around AMD SYSRET SS descriptor attribute issueAndy Lutomirski2015-04-275-0/+48
| | | | | | | | | | | | | | | | | | | AMD CPUs don't reinitialize the SS descriptor on SYSRET, so SYSRET with SS == 0 results in an invalid usermode state in which SS is apparently equal to __USER_DS but causes #SS if used. Work around the issue by setting SS to __KERNEL_DS __switch_to, thus ensuring that SYSRET never happens with SS set to NULL. This was exposed by a recent vDSO cleanup. Fixes: e7d6eefaaa44 x86/vdso32/syscall.S: Do not load __USER32_DS to %ss Signed-off-by: Andy Lutomirski <luto@kernel.org> Cc: Peter Anvin <hpa@zytor.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Denys Vlasenko <vda.linux@googlemail.com> Cc: Brian Gerst <brgerst@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linuxLinus Torvalds2015-04-275-14/+95
|\ | | | | | | | | | | | | | | | | Pull intel drm fixes from Dave Airlie. * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: drm/i915: vlv: fix save/restore of GFX_MAX_REQ_COUNT reg drm/i915: Workaround to avoid lite restore with HEAD==TAIL drm/i915: cope with large i2c transfers
| * Merge tag 'drm-intel-next-fixes-2015-04-25' of ↵Dave Airlie2015-04-275-14/+95
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm-intel into drm-fixes three fixes for i915. * tag 'drm-intel-next-fixes-2015-04-25' of git://anongit.freedesktop.org/drm-intel: drm/i915: vlv: fix save/restore of GFX_MAX_REQ_COUNT reg drm/i915: Workaround to avoid lite restore with HEAD==TAIL drm/i915: cope with large i2c transfers
| | * drm/i915: vlv: fix save/restore of GFX_MAX_REQ_COUNT regImre Deak2015-04-231-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Due this typo we don't save/restore the GFX_MAX_REQ_COUNT register across suspend/resume, so fix this. This was introduced in commit ddeea5b0c36f3665446518c609be91f9336ef674 Author: Imre Deak <imre.deak@intel.com> Date: Mon May 5 15:19:56 2014 +0300 drm/i915: vlv: add runtime PM support I noticed this only by reading the code. To my knowledge it shouldn't cause any real problems at the moment, since the power well backing this register remains on across a runtime s/r. This may change once system-wide s0ix functionality is enabled in the kernel. v2: - resend after a missing git add -u :/ Cc: stable@vger.kernel.org Signed-off-by: Imre Deak <imre.deak@intel.com> Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang.he@intel.com) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| | * drm/i915: Workaround to avoid lite restore with HEAD==TAILMichel Thierry2015-04-232-2/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | WaIdleLiteRestore is an execlists-only workaround, and requires the driver to ensure that any context always has HEAD!=TAIL when attempting lite restore. Add two extra MI_NOOP instructions at the end of each request, but keep the requests tail pointing before the MI_NOOPs. We may not need to executed them, and this is why request->tail is sampled before adding these extra instructions. If we submit a context to the ELSP which has previously been submitted, move the tail pointer past the MI_NOOPs. This ensures HEAD!=TAIL. v2: Move overallocation to gen8_emit_request, and added note about sampling request->tail in commit message (Chris). v3: Remove redundant request->tail assignment in __i915_add_request, in lrc mode this is already set in execlists_context_queue. Do not add wa implementation details inside gem (Chris). v4: Apply the wa whenever the req has been resubmitted and update comment (Chris). Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Thomas Daniel <thomas.daniel@intel.com> Signed-off-by: Michel Thierry <michel.thierry@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| | * drm/i915: cope with large i2c transfersDmitry Torokhov2015-04-232-10/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The hardware, according to the specs, is limited to 256 byte transfers, and current driver has no protections in case users attempt to do larger transfers. The code will just stomp over status register and mayhem ensues. Let's split larger transfers into digestable chunks. Doing this allows Atmel MXT driver on Pixel 1 function properly (it hasn't since commit 9d8dc3e529a19e427fd379118acd132520935c5d "Input: atmel_mxt_ts - implement T44 message handling" which tries to consume multiple touchscreen/touchpad reports in a single transaction). Cc: stable@vger.kernel.org Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* | | Merge git://git.infradead.org/intel-iommuLinus Torvalds2015-04-273-83/+82
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull intel iommu updates from David Woodhouse: "This lays a little of the groundwork for upcoming Shared Virtual Memory support — fixing some bogus #defines for capability bits and adding the new ones, and starting to use the new wider page tables where we can, in anticipation of actually filling in the new fields therein. It also allows graphics devices to be assigned to VM guests again. This got broken in 3.17 by disallowing assignment of RMRR-afflicted devices. Like USB, we do understand why there's an RMRR for graphics devices — and unlike USB, it's actually sane. So we can make an exception for graphics devices, just as we do USB controllers. Finally, tone down the warning about the X2APIC_OPT_OUT bit, due to persistent requests. X2APIC_OPT_OUT was added to the spec as a nasty hack to allow broken BIOSes to forbid us from using X2APIC when they do stupid and invasive things and would break if we did. Someone noticed that since Windows doesn't have full IOMMU support for DMA protection, setting the X2APIC_OPT_OUT bit made Windows avoid initialising the IOMMU on the graphics unit altogether. This means that it would be available for use in "driver mode", where the IOMMU registers are made available through a BAR of the graphics device and the graphics driver can do SVM all for itself. So they started setting the X2APIC_OPT_OUT bit on *all* platforms with SVM capabilities. And even the platforms which *might*, if the planets had been aligned correctly, possibly have had SVM capability but which in practice actually don't" * git://git.infradead.org/intel-iommu: iommu/vt-d: support extended root and context entries iommu/vt-d: Add new extended capabilities from v2.3 VT-d specification iommu/vt-d: Allow RMRR on graphics devices too iommu/vt-d: Print x2apic opt out info instead of printing a warning iommu/vt-d: kill bogus ecap_niotlb_iunits()
| * | | iommu/vt-d: support extended root and context entriesDavid Woodhouse2015-03-251-75/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a new function iommu_context_addr() which takes care of the differences and returns a pointer to a context entry which may be in either format. The formats are binary compatible for all the old fields anyway; the new one is just larger and some of the reserved bits in the original 128 are now meaningful. So far, nothing actually uses the new fields in the extended context entry. Modulo hardware bugs with interpreting the new-style tables, this should basically be a no-op. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
| * | | iommu/vt-d: Add new extended capabilities from v2.3 VT-d specificationDavid Woodhouse2015-03-251-0/+14
| | | | | | | | | | | | | | | | Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
| * | | iommu/vt-d: Allow RMRR on graphics devices tooDavid Woodhouse2015-03-251-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit c875d2c1 ("iommu/vt-d: Exclude devices using RMRRs from IOMMU API domains") prevents certain options for devices with RMRRs. This even prevents those devices from getting a 1:1 mapping with 'iommu=pt', because we don't have the code to handle *preserving* the RMRR regions when moving the device between domains. There's already an exclusion for USB devices, because we know the only reason for RMRRs there is a misguided desire to keep legacy keyboard/mouse emulation running in some theoretical OS which doesn't have support for USB in its own right... but which *does* enable the IOMMU. Add an exclusion for graphics devices too, so that 'iommu=pt' works there. We should be able to successfully assign graphics devices to guests too, as long as the initial handling of stolen memory is reconfigured appropriately. This has certainly worked in the past. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> Cc: stable@vger.kernel.org
| * | | iommu/vt-d: Print x2apic opt out info instead of printing a warningFenghua Yu2015-03-251-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BIOS can set up x2apic_opt_out bit on some platforms, for various misguided reasons like insane SMM code with weird assumptions about what descriptors look like, or wanting Windows not to enable the IOMMU so that the graphics driver will take it over for SVM in "driver mode". A user can either disable the x2apic_opt_out bit in BIOS or by kernel parameter "no_x2apic_optout". Instead of printing a warning, we just print information of x2apic opt out. Signed-off-by: Fenghua Yu <fenghua.yu@intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
| * | | iommu/vt-d: kill bogus ecap_niotlb_iunits()David Woodhouse2015-03-251-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As far back as I can see (which right now is a draft of the v1.2 spec dating from September 2008), bits 24-31 of the Extended Capability Register have already been reserved. I have no idea why anyone ever thought there would be multiple sets of IOTLB registers, but we've never supported them and all we do is make sure we map enough MMIO space for them. Kill it dead. Those bits do actually have a different meaning now. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
* | | | Merge branch 'i2c/for-next' of ↵Linus Torvalds2015-04-277-14/+18
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux Pull i2c fixes from Wolfram Sang: "This has a mixture of merge window cleanups and bugfixes" * 'i2c/for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: i2c: st: add include for pinctrl i2c: mux: use proper dev when removing "channel-X" symlinks i2c: digicolor: remove duplicate include i2c: Mark adapter devices with pm_runtime_no_callbacks i2c: pca-platform: fix broken email address i2c: mxs: fix broken email address i2c: rk3x: report number of messages transmitted
| * | | | i2c: st: add include for pinctrlWolfram Sang2015-04-231-6/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The driver uses pinctrl directly and thus should include the appropriate header. Sort the headers while we are here to have a better view what is included and what is not. Reported-by: Pascal Huerst <pascal.huerst@gmail.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
| * | | | i2c: mux: use proper dev when removing "channel-X" symlinksWolfram Sang2015-04-231-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Those symlinks are created for the mux_dev, so we need to remove it from there. Currently, it breaks for muxes where the mux_dev is not the device of the parent adapter like this: [ 78.234644] WARNING: CPU: 0 PID: 365 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x5c/0x78() [ 78.242438] sysfs: cannot create duplicate filename '/devices/platform/i2cbus@8/channel-0' Remove confusing comments while we are here. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Fixes: c9449affad2ae0 Cc: stable@kernel.org
| * | | | i2c: digicolor: remove duplicate includeWolfram Sang2015-04-231-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | And sort them to prevent this from happening again. Reported-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
| * | | | i2c: Mark adapter devices with pm_runtime_no_callbacksCharles Keepax2015-04-231-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 523c5b89640e ("i2c: Remove support for legacy PM") removed the PM ops from the bus type, which causes the pm operations on the s3c2410 adapter device to fail (-ENOSUPP in rpm_callback). The adapter device doesn't get bound to a driver and as such can't have its own pm_runtime callbacks. Previously this was fine as the bus callbacks would have been used, but now this can cause devices which use PM runtime and are attached over I2C to fail to resume. This commit fixes this issue by marking all adapter devices with pm_runtime_no_callbacks, since they can't have any. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Acked-by: Beata Michalska <b.michalska@samsung.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Fixes: 523c5b89640e Cc: stable@kernel.org
| * | | | i2c: pca-platform: fix broken email addressWolfram Sang2015-04-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | My Pengutronix address is not valid anymore, redirect people to the Pengutronix kernel team. Reported-by: Harald Geyer <harald@ccbib.org> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Acked-by: Robert Schwebel <r.schwebel@pengutronix.de>
| * | | | i2c: mxs: fix broken email addressWolfram Sang2015-04-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | My Pengutronix address is not valid anymore, redirect people to the Pengutronix kernel team. Reported-by: Harald Geyer <harald@ccbib.org> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Acked-by: Robert Schwebel <r.schwebel@pengutronix.de>
| * | | | i2c: rk3x: report number of messages transmittedDmitry Torokhov2015-04-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | master_xfer() method should return number of i2c messages transferred, but on Rockchip we were usually returning just 1, which caused trouble with users that actually check number of transferred messages vs. checking for negative error codes. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Cc: stable@kernel.org
* | | | | Merge branch 'for-linus-4.1' of ↵Linus Torvalds2015-04-271-17/+25
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs Pull btrfs fixes from Chris Mason: "Filipe hit two problems in my block group cache patches. We finalized the fixes last week and ran through more tests" * 'for-linus-4.1' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs: Btrfs: prevent list corruption during free space cache processing Btrfs: fix inode cache writeout
| * | | | | Btrfs: prevent list corruption during free space cache processingChris Mason2015-04-241-14/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | __btrfs_write_out_cache is holding the ctl->tree_lock while it prepares a list of bitmaps to record in the free space cache. It was dropping the lock while it worked on other components, which made a window for free_bitmap() to free the bitmap struct without removing it from the list. This changes things to hold the lock the whole time, and also makes sure we hold the lock during enospc cleanup. Reported-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Chris Mason <clm@fb.com>
| * | | | | Btrfs: fix inode cache writeoutChris Mason2015-04-241-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The code to fix stalls during free spache cache IO wasn't using the correct root when waiting on the IO for inode caches. This is only a problem when the inode cache is enabled with mount -o inode_cache This fixes the inode cache writeout to preserve any error values and makes sure not to override the root when inode cache writeout is done. Reported-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Chris Mason <clm@fb.com>
* | | | | | Merge tag 'nfs-for-4.1-1' of git://git.linux-nfs.org/projects/trondmy/linux-nfsLinus Torvalds2015-04-2749-914/+1150
|\ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull NFS client updates from Trond Myklebust: "Another set of mainly bugfixes and a couple of cleanups. No new functionality in this round. Highlights include: Stable patches: - Fix a regression in /proc/self/mountstats - Fix the pNFS flexfiles O_DIRECT support - Fix high load average due to callback thread sleeping Bugfixes: - Various patches to fix the pNFS layoutcommit support - Do not cache pNFS deviceids unless server notifications are enabled - Fix a SUNRPC transport reconnection regression - make debugfs file creation failure non-fatal in SUNRPC - Another fix for circular directory warnings on NFSv4 "junctioned" mountpoints - Fix locking around NFSv4.2 fallocate() support - Truncating NFSv4 file opens should also sync O_DIRECT writes - Prevent infinite loop in rpcrdma_ep_create() Features: - Various improvements to the RDMA transport code's handling of memory registration - Various code cleanups" * tag 'nfs-for-4.1-1' of git://git.linux-nfs.org/projects/trondmy/linux-nfs: (55 commits) fs/nfs: fix new compiler warning about boolean in switch nfs: Remove unneeded casts in nfs NFS: Don't attempt to decode missing directory entries Revert "nfs: replace nfs_add_stats with nfs_inc_stats when add one" NFS: Rename idmap.c to nfs4idmap.c NFS: Move nfs_idmap.h into fs/nfs/ NFS: Remove CONFIG_NFS_V4 checks from nfs_idmap.h NFS: Add a stub for GETDEVICELIST nfs: remove WARN_ON_ONCE from nfs_direct_good_bytes nfs: fix DIO good bytes calculation nfs: Fetch MOUNTED_ON_FILEID when updating an inode sunrpc: make debugfs file creation failure non-fatal nfs: fix high load average due to callback thread sleeping NFS: Reduce time spent holding the i_mutex during fallocate() NFS: Don't zap caches on fallocate() xprtrdma: Make rpcrdma_{un}map_one() into inline functions xprtrdma: Handle non-SEND completions via a callout xprtrdma: Add "open" memreg op xprtrdma: Add "destroy MRs" memreg op xprtrdma: Add "reset MRs" memreg op ...
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-28 18:34:35 +0100