- 18 Apr, 2017 1 commit
-
-
Imre Deak authored
commit d253371c upstream. After commit 2c7d0602 Author: Imre Deak <imre.deak@intel.com> Date: Mon Dec 5 18:27:37 2016 +0200 drm/i915/gen9: Fix PCODE polling during CDCLK change notification there is still one report of the CDCLK-change request timing out on a KBL machine, see the Reference link. On that machine the maximum time the request took to succeed was 34ms, so increase the timeout to 50ms. v2: - Change timeout from 100 to 50 ms to maintain the current 50 ms limit for atomic waits in the driver. (Chris, Tvrtko) Reference: https://bugs.freedesktop.org/show_bug.cgi?id=99345 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Acked-by:
Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1487946730-17162-1-git-send-email-imre.deak@intel.com (cherry picked from commit 0129936d) Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 12 Apr, 2017 39 commits
-
-
Greg Kroah-Hartman authored
-
Matjaz Hegedic authored
[ Upstream commit bba8376a ] The reboot quirk for ASUS EeeBook X205TA contains a typo in DMI_PRODUCT_NAME, improperly referring to X205TAW instead of X205TA, which prevents the quirk from being triggered. The model X205TAW already has a reboot quirk of its own. This fix simply removes the inappropriate final letter W. Fixes: 90b28ded ("x86/reboot/quirks: Add ASUS EeeBook X205TA reboot quirk") Signed-off-by:
Matjaz Hegedic <matjaz.hegedic@gmail.com> Link: http://lkml.kernel.org/r/1489064417-7445-1-git-send-email-matjaz.hegedic@gmail.comSigned-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Sasha Levin <alexander.levin@verizon.com> Signed-off-by:
-
Tobias Jakobi authored
[ Upstream commit d595259f ] This USB-SATA bridge chip is used in a StarTech enclosure for optical drives. Without the quirk MakeMKV fails during the key exchange with an installed BluRay drive: > Error 'Scsi error - ILLEGAL REQUEST:COPY PROTECTION KEY EXCHANGE FAILURE - KEY NOT ESTABLISHED' > occurred while issuing SCSI command AD010..080002400 to device 'SG:dev_11:2' Signed-off-by:
Tobias Jakobi <tjakobi@math.uni-bielefeld.de> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Matjaz Hegedic authored
[ Upstream commit 3b3e7855 ] Without the parameter reboot=a, ASUS EeeBook X205TA/W will hang when it should reboot. This adds the appropriate quirk, thus fixing the problem. Signed-off-by:
-
Matjaz Hegedic authored
[ Upstream commit 90b28ded ] Without the parameter reboot=a, ASUS EeeBook X205TA will hang when it should reboot. This adds the appropriate quirk, thus fixing the problem. Signed-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
João Paulo Rechi Vita authored
[ Upstream commit 71050ae7 ] Some Asus laptops that have an airplane-mode indicator LED, also have the WMI WLAN user bit set, and the following bits in their DSDT: Scope (_SB) { (...) Device (ATKD) { (...) Method (WMNB, 3, Serialized) { (...) If (LEqual (IIA0, 0x00010002)) { OWGD (IIA1) Return (One) } } } } So when asus-wmi uses ASUS_WMI_DEVID_WLAN_LED (0x00010002) to store the wlan state, it drives the airplane-mode indicator LED (through the call to OWGD) in an inverted fashion: the LED is ON when airplane mode is OFF (since wlan is ON), and vice-versa. This commit skips registering RFKill switches at all for these laptops, to allow the asus-wireless driver to drive the airplane mode LED correctly through the ASHS ACPI device. Relying on the presence of ASHS and ASUS_WMI_DSTS_USER_BIT avoids adding DMI-based quirks for at least 21 different laptops. Signed-off-by:
João Paulo Rechi Vita <jprvita@endlessm.com> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Kai-Chuan Hsieh authored
[ Upstream commit 8023eff1 ] 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:
-
Krzysztof Kozlowski authored
[ Upstream commit 0b445549 ] In soft (no-reboot) mode, the driver self-pings watchdog upon expiration of an interrupt. However the interrupt itself was not cleared thus on first hit, the system enters infinite interrupt handling loop. On Odroid U3 (Exynos4412), when booted with s3c2410_wdt.soft_noboot=1 argument the console is flooded: # killall -9 watchdog [ 60.523760] s3c2410-wdt 10060000.watchdog: watchdog timer expired (irq) [ 60.536744] s3c2410-wdt 10060000.watchdog: watchdog timer expired (irq) Fix this by writing something to the WTCLRINT register to clear the interrupt. The register WTCLRINT however appeared in S3C6410 so a new watchdog quirk and flavor are needed. Signed-off-by:
Krzysztof Kozlowski <krzk@kernel.org> Reviewed-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Sinan Kaya authored
[ Upstream commit 33be632b ] The Qualcomm QDF2xxx root ports don't advertise an ACS capability, but they do provide ACS-like features to disable peer transactions and validate bus numbers in requests. To be specific: * Hardware supports source validation but it will report the issue as Completer Abort instead of ACS Violation. * Hardware doesn't support peer-to-peer and each root port is a root complex with unique segment numbers. * It is not possible for one root port to pass traffic to the other root port. All PCIe transactions are terminated inside the root port. Add an ACS quirk for the QDF2400 and QDF2432 products. [bhelgaas: changelog] Signed-off-by:
Sinan Kaya <okaya@codeaurora.org> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Reviewed-by:
Alex Williamson <alex.williamson@redhat.com> Signed-off-by:
-
Andy Shevchenko authored
[ Upstream commit cd3e2eb8 ] Sort the list of Intel devices that have no PCI D3 delay by ID. Add a comment for group of devices that had not been marked yet. There is no functional change. Signed-off-by:
-
yangbo lu authored
[ Upstream commit e9acc77d ] Initially all QorIQ platforms were PowerPC architecture and they didn't support card detection except several platforms. The driver added the quirk SDHCI_QUIRK_BROKEN_CARD_DETECTION as default and this made broken-cd property in dts node didn't work. Now QorIQ platform turns to ARM architecture and most of them could support card detection. However it's a large number of dts trees that need to be fixed with broken-cd if we remove the default SDHCI_QUIRK_BROKEN_CARD_DETECTION in driver. And the users don't want to see this. So this patch is to remove this default quirk just for ARM and keep it for PowerPC.(Note, QorIQ PowerPC platform only has big-endian eSDHC while QorIQ ARM platform has big-endian or little-endian eSDHC) This makes broken-cd property work again for ARM. Signed-off-by:
Yangbo Lu <yangbo.lu@nxp.com> Acked-by:
Adrian Hunter <adrian.hunter@intel.com> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Dongdong Liu authored
[ Upstream commit 72f2ff0d ] The PCIe Root Port in Hip06/Hip07 SoCs advertises an MSI capability, but it cannot generate MSIs. It can transfer MSI/MSI-X from downstream devices, but does not support MSI/MSI-X itself. Add a quirk to prevent use of MSI/MSI-X by the Root Port. [bhelgaas: changelog, sort vendor ID #define, drop device ID #define] Signed-off-by:
Dongdong Liu <liudongdong3@huawei.com> Signed-off-by:
Gabriele Paoloni <gabriele.paoloni@huawei.com> Reviewed-by:
Zhou Wang <wangzhou1@hisilicon.com> Signed-off-by:
-
Jon Mason authored
[ Upstream commit ce709f86 ] The Broadcom Northstar2 SoC has a number of quirks for the PAXC (internal/fake) PCI bus. Specifically, the PCI config space is shared between the root port and the first PF (ie., PF0), and a number of fields are tied to zero (thus preventing them from being set). These cannot be "fixed" in device firmware, so we must fix them with a quirk. Signed-off-by:
Jon Mason <jon.mason@broadcom.com> Signed-off-by:
-
Will Deacon authored
[ Upstream commit 3046ec67 ] Commit 680a0873 ("arm: kernel: Add SMC structure parameter") added a new "quirk" parameter to the SMC and HVC SMCCC backends, but only updated the comment for the SMC version. This patch adds the new paramater to the comment describing the HVC version too. Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Baoyou Xie authored
[ Upstream commit a5725ab0 ] We get 2 warnings when building kernel with W=1: drivers/gpu/drm/msm/adreno/a3xx_gpu.c:535:17: warning: no previous prototype for 'a3xx_gpu_init' [-Wmissing-prototypes] drivers/gpu/drm/msm/adreno/a4xx_gpu.c:624:17: warning: no previous prototype for 'a4xx_gpu_init' [-Wmissing-prototypes] In fact, both functions are declared in drivers/gpu/drm/msm/adreno/adreno_device.c, but should be declared in a header file. So this patch moves both function declarations to drivers/gpu/drm/msm/adreno/adreno_gpu.h. Signed-off-by:
Baoyou Xie <baoyou.xie@linaro.org> Reviewed-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1477127865-9381-1-git-send-email-baoyou.xie@linaro.orgSigned-off-by:
-
Andy Gross authored
[ Upstream commit 82bcd087 ] This patch adds a Qualcomm specific quirk to the arm_smccc_smc call. On Qualcomm ARM64 platforms, the SMC call can return before it has completed. If this occurs, the call can be restarted, but it requires using the returned session ID value from the interrupted SMC call. The quirk stores off the session ID from the interrupted call in the quirk structure so that it can be used by the caller. This patch folds in a fix given by Sricharan R: https://lkml.org/lkml/2016/9/28/272Signed-off-by:
Andy Gross <andy.gross@linaro.org> Reviewed-by:
-
Andy Gross authored
[ Upstream commit 680a0873 ] This patch adds a quirk parameter to the arm_smccc_(smc/hvc) calls. The quirk structure allows for specialized SMC operations due to SoC specific requirements. The current arm_smccc_(smc/hvc) is renamed and macros are used instead to specify the standard arm_smccc_(smc/hvc) or the arm_smccc_(smc/hvc)_quirk function. This patch and partial implementation was suggested by Will Deacon. Signed-off-by:
-
Ping Cheng authored
[ Upstream commit e7deb157 ] Non-generic devices have numbered_buttons set for both pen and touch interfaces by default. The actual number of buttons on the interface is normally manually decided later, which is different from what those HID generic devices are processed, where number of buttons are directly retrieved from HID descriptors. This patch adds the missed HID_GENERIC check and moves the statement to wacom_setup_pad_input_capabilities since it's not a quirk anymore. Signed-off-by:
Ping Cheng <ping.cheng@wacom.com> Reviewed-by:
Jason Gerecke <jason.gerecke@wacom.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Mylène Josserand authored
[ Upstream commit 2ad6f30d ] Some SoCs have a reset line that must be asserted/deasserted. This patch adds a quirk to handle the new compatible "allwinner,sun6i-a31-i2s" which will deassert the reset line on probe function and assert it on remove's one. This new compatible is useful in case of A33 codec driver, for example. Signed-off-by:
Mylène Josserand <mylene.josserand@free-electrons.com> Acked-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Zhang Rui authored
[ Upstream commit cbc00c13 ] In commit 821d6f03 (ACPI / sleep: Do not save NVS for new machines to accelerate S3), to optimize S3 suspend/resume speed, code is introduced to ignore NVS memory saving during S3 for all the platforms later than 2012. But, Lenovo G50-45, a platform released in 2015, still needs NVS memory saving during S3. A quirk is introduced for this platform. Link: https://bugzilla.kernel.org/show_bug.cgi?id=189431Tested-by:
Przemek <soprwa@gmail.com> Signed-off-by:
Zhang Rui <rui.zhang@intel.com> [ rjw: Drop unnecessary code ] Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Pierre-Louis Bossart authored
[ Upstream commit a50477e5 ] The existing code assumes a 19.2 MHz MCLK as the default hardware configuration. This is valid for CherryTrail but not for Baytrail. Add explicit MCLK configuration to set the 19.2 clock on/off depending on DAPM events. This is a prerequisite step to enable devices with Baytrail and RT5645 such as Asus X205TA Signed-off-by:
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by:
-
Pierre-Louis Bossart authored
[ Upstream commit 42648c22 ] Fix classic issue of having multiple codecs listed in DSDT but a single one actually enabled. The previous code did not handle such errors and could also lead to uninitalized configurations Signed-off-by:
-
Pierre-Louis Bossart authored
[ Upstream commit fd0138dc ] the BIOS reports this codec as RT5640 but it's a rt5670. Use the quirk mechanism to use the cht_bsw_rt5672 machine driver Signed-off-by:
-
Pierre-Louis Bossart authored
[ Upstream commit 93ffeaa8 ] the BIOS incorrectly reports this codec as 5640 but it is really a rt5670 Signed-off-by:
-
Takashi Iwai authored
[ Upstream commit d2528006 ] rt5670 driver supports also RT5672 codec, but its ACPI ID is missing. This was found on Dell Wyse 3040 box. Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Lv Zheng authored
[ Upstream commit 77e9a4aa ] More and more platforms need the button.lid_init_state=open quirk. This patch sets it the default behavior. If a platform doesn't send lid open event or lid open event is lost due to the underlying system problems, then we can compare various combinations: 1. systemd/acpid is used to suspend system or not, systemd has a special logic forcing open event after resuming; 2. _LID returns a cached value or not. The result is as follows: 1. lid_init_state=method 1. cached 1. resumed by lid: (x) event=close (x) systemd=suspends again (x) acpid=suspends again (x) state=close 2. resumed by other: (o) event=close (x) systemd=suspends again (x) acpid=suspends again (o) state=close 2. non-cached 1. resumed by lid: (o) event=open (o) systemd=resumes (o) acpid=resumes (o) state=open 2. resumed by other: (o) event=close (x) systemd=suspends again (x) acpid=suspends again (o) state=close 2. lid_init_state=open 1. cached 1. resumed by lid: (o) event=open (o) systemd=resumes (o) acpid=resumes (x) state=close 2. resumed by other: (x) event=open (o) systemd=resumes (o) acpid=resumes (o) state=close 2. non-cached 1. resumed by lid: (o) event=open (o) systemd=resumes (o) acpid=resumes (o) state=open 2. resumed by other: (x) event=open (o) systemd=resumes (o) acpid=resumes (o) state=close 3. lid_init_state=ignore 1. cached 1. resumed by lid: (o) event=none (x) systemd=suspends again (o) acpid=resumes (x) state=close 2. resumed by other: (o) event=none (x) systemd=suspends again (o) acpid=resumes (o) state=close 2. non-cached 1. resumed by lid: (o) event=none (x) systemd=suspends again (o) acpid=resumes (o) state=open 2. resumed by other: (o) event=none (x) systemd=suspends again (o) acpid=resumes (o) state=close As a conclusion: 1. With systemd changed, lid_init_state=ignore has only one problem and the problem comes from an underlying issue, not userspace and kernel lid handling. 2. Without systemd changed, lid_init_state=open can be the default behavior as the pass ratio is not much worse than lid_init_state=ignore. 3. lid_init_state=method is buggy, we can have a separate patch to make it deprectated. Link: https://bugzilla.kernel.org/show_bug.cgi?id=187271Signed-off-by:
Lv Zheng <lv.zheng@intel.com> Signed-off-by:
-
Bartosz Golaszewski authored
[ Upstream commit f4d435f3 ] There's an issue with the da850 SATA controller: if port multiplier support is compiled in, but we're connecting the drive directly to the SATA port on the board, the drive can't be detected. To make SATA work on the da850-lcdk board: first try to softreset with pmp - if the operation fails with -EBUSY, retry without pmp. Signed-off-by:
Bartosz Golaszewski <bgolaszewski@baylibre.com> Acked-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
Sekhar Nori <nsekhar@ti.com> Signed-off-by:
-
Alex Williamson authored
[ Upstream commit 7184f5b4 ] Intel 200-series chipsets have the same errata as 100-series: the ACS capability doesn't follow the PCIe spec, the capability and control registers are dwords rather than words. Add PCIe root port device IDs to existing quirk. Signed-off-by:
-
Patrice Chotard authored
[ Upstream commit 8413299c ] Since v4.10-rc1, the following logs appears in loop : [ 801.953836] usb usb6-port1: Cannot enable. Maybe the USB cable is bad? [ 801.960455] xhci-hcd xhci-hcd.0.auto: Cannot set link state. [ 801.966611] usb usb6-port1: cannot disable (err = -32) [ 806.083772] usb usb6-port1: Cannot enable. Maybe the USB cable is bad? [ 806.090370] xhci-hcd xhci-hcd.0.auto: Cannot set link state. [ 806.096494] usb usb6-port1: cannot disable (err = -32) After analysis, xhci try to set link in U3 and returns an error. Using snps,dis_u3_susphy_quirk fix this issue. Signed-off-by:
Patrice Chotard <patrice.chotard@st.com> Signed-off-by:
-
Daniel Vetter authored
[ Upstream commit 858b2c1b ] It's only for a device quirk, and we might as well do that in the load callback. Acked-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170125062657.19270-10-daniel.vetter@ffwll.chSigned-off-by:
-
Felipe Balbi authored
[ Upstream commit e42a5dbb ] dwc3 revisions <=3.00a have a limitation where Port Disable command doesn't work. Set the quirk-broken-port-ped property for such controllers so XHCI core can do the necessary workaround. [rogerq@ti.com] Updated code from platform data to device property. Signed-off-by:
Roger Quadros <rogerq@ti.com> Signed-off-by:
Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by:
-
Felipe Balbi authored
[ Upstream commit 21939f00 ] In case 'quirk-broken-port-ped' property is passed in via device property, we should enable the corresponding BROKEN_PED quirk flag for XHCI core. [rogerq@ti.com] Updated code from platform data to device property and added DT binding. Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
-
Felipe Balbi authored
[ Upstream commit 41135de1 ] Some devices from Texas Instruments [1] suffer from a silicon bug where Port Enabled/Disabled bit should not be used to silence an erroneous device. The bug is so that if port is disabled with PED bit, an IRQ for device removal (or attachment) will never fire. Just for the sake of completeness, the actual problem lies with SNPS USB IP and this affects all known versions up to 3.00a. A separate patch will be added to dwc3 to enabled this quirk flag if version is <= 3.00a. [1] - AM572x Silicon Errata http://www.ti.com/lit/er/sprz429j/sprz429j.pdf Section i896— USB xHCI Port Disable Feature Does Not Work Signed-off-by:
-
Kevin Hilman authored
[ Upstream commit 7e431af8 ] Add PM support for DA850 device-tree boot. Signed-off-by:
Kevin Hilman <khilman@baylibre.com> Signed-off-by:
-
Geert Uytterhoeven authored
[ Upstream commit 5feeca3c ] GPIO descriptors are the preferred way over legacy GPIO numbers nowadays. Convert the driver to use GPIO descriptors internally but still allow passing legacy GPIO numbers from platform data to support existing platforms. Based on commits 633a21d8 ("input: gpio_keys_polled: Add support for GPIO descriptors") and 1ae5ddb6 ("Input: gpio_keys_polled - request GPIO pin as input."). Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Tested-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Vignesh R authored
[ Upstream commit b6ffcf21 ] UART uses as EDMA as dma engine on AM437x SoC and therefore, requires OMAP_DMA_TX_KICK quirk just like AM33xx. So, enable OMAP_DMA_TX_KICK quirk for AM437x platform as well. While at that, drop use of of_machine_is_compatible() and instead pass quirks via device data. Signed-off-by:
Vignesh R <vigneshr@ti.com> Acked-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Stephen Boyd authored
[ Upstream commit dd374909 ] The core framework already handles setting this parameter with a platform quirk. Add the appropriate flag so that we always set AHBBURST to 0. Technically DT should be doing this, but we always do it for msm chipidea devices so setting the flag in the driver works just as well. If the burst needs to be anything besides 0, we expect the 'ahb-burst-config' dts property to be present. Acked-by:
Peter Chen <peter.chen@nxp.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Stephen Boyd <stephen.boyd@linaro.org> Signed-off-by:
-
subhashj@codeaurora.org authored
[ Upstream commit 7caf489b ] If we issue the link startup to the device while its UniPro state is LinkDown (and device state is sleep/power-down) then link startup will not move the device state to Active. Device will only move to active state if the link starup is issued when its UniPro state is LinkUp. So in this case, we would have to issue the link startup 2 times to make sure that device moves to active state. Reviewed-by:
Gilad Broner <gbroner@codeaurora.org> Signed-off-by:
Subhash Jadavani <subhashj@codeaurora.org> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Zang Leigang authored
[ Upstream commit 141f8165 ] Add a new ufshcd_state, indicats that an err handler may get to run immediately. Use UFSHCD_STATE_ERROR here looks not literaly correct. Signed-off-by:
Zang Leigang <zangleigang@hisilicon.com> Reviewed-by:
-
