--- /dev/null
+From 65766ee0bf7fe8b3be80e2e1c3ef54ad59b29476 Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Fri, 9 Nov 2018 11:59:45 +0100
+Subject: ALSA: oss: Use kvzalloc() for local buffer allocations
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit 65766ee0bf7fe8b3be80e2e1c3ef54ad59b29476 upstream.
+
+PCM OSS layer may allocate a few temporary buffers, one for the core
+read/write and another for the conversions via plugins. Currently
+both are allocated via vmalloc(). But as the allocation size is
+equivalent with the PCM period size, the required size might be quite
+small, depending on the application.
+
+This patch replaces these vmalloc() calls with kvzalloc() for covering
+small period sizes better. Also, we use "z"-alloc variant here for
+addressing the possible uninitialized access reported by syzkaller.
+
+Reported-by: syzbot+1cb36954e127c98dd037@syzkaller.appspotmail.com
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/core/oss/pcm_oss.c | 6 +++---
+ sound/core/oss/pcm_plugin.c | 6 +++---
+ 2 files changed, 6 insertions(+), 6 deletions(-)
+
+--- a/sound/core/oss/pcm_oss.c
++++ b/sound/core/oss/pcm_oss.c
+@@ -1062,8 +1062,8 @@ static int snd_pcm_oss_change_params_loc
+ runtime->oss.channels = params_channels(params);
+ runtime->oss.rate = params_rate(params);
+
+- vfree(runtime->oss.buffer);
+- runtime->oss.buffer = vmalloc(runtime->oss.period_bytes);
++ kvfree(runtime->oss.buffer);
++ runtime->oss.buffer = kvzalloc(runtime->oss.period_bytes, GFP_KERNEL);
+ if (!runtime->oss.buffer) {
+ err = -ENOMEM;
+ goto failure;
+@@ -2328,7 +2328,7 @@ static void snd_pcm_oss_release_substrea
+ {
+ struct snd_pcm_runtime *runtime;
+ runtime = substream->runtime;
+- vfree(runtime->oss.buffer);
++ kvfree(runtime->oss.buffer);
+ runtime->oss.buffer = NULL;
+ #ifdef CONFIG_SND_PCM_OSS_PLUGINS
+ snd_pcm_oss_plugin_clear(substream);
+--- a/sound/core/oss/pcm_plugin.c
++++ b/sound/core/oss/pcm_plugin.c
+@@ -66,8 +66,8 @@ static int snd_pcm_plugin_alloc(struct s
+ return -ENXIO;
+ size /= 8;
+ if (plugin->buf_frames < frames) {
+- vfree(plugin->buf);
+- plugin->buf = vmalloc(size);
++ kvfree(plugin->buf);
++ plugin->buf = kvzalloc(size, GFP_KERNEL);
+ plugin->buf_frames = frames;
+ }
+ if (!plugin->buf) {
+@@ -191,7 +191,7 @@ int snd_pcm_plugin_free(struct snd_pcm_p
+ if (plugin->private_free)
+ plugin->private_free(plugin);
+ kfree(plugin->buf_channels);
+- vfree(plugin->buf);
++ kvfree(plugin->buf);
+ kfree(plugin);
+ return 0;
+ }
--- /dev/null
+From d1fe6ad6f6bd61c84788d3a7b11e459a439c6169 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= <rafal@milecki.pl>
+Date: Thu, 8 Nov 2018 16:08:29 +0100
+Subject: brcmfmac: fix reporting support for 160 MHz channels
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Rafał Miłecki <rafal@milecki.pl>
+
+commit d1fe6ad6f6bd61c84788d3a7b11e459a439c6169 upstream.
+
+Driver can report IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ so it's
+important to provide valid & complete info about supported bands for
+each channel. By default no support for 160 MHz should be assumed unless
+firmware reports it for a given channel later.
+
+This fixes info passed to the userspace. Without that change userspace
+could try to use invalid channel and fail to start an interface.
+
+Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
+Cc: stable@vger.kernel.org
+Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
++++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+@@ -5997,7 +5997,8 @@ static int brcmf_construct_chaninfo(stru
+ * for subsequent chanspecs.
+ */
+ channel->flags = IEEE80211_CHAN_NO_HT40 |
+- IEEE80211_CHAN_NO_80MHZ;
++ IEEE80211_CHAN_NO_80MHZ |
++ IEEE80211_CHAN_NO_160MHZ;
+ ch.bw = BRCMU_CHAN_BW_20;
+ cfg->d11inf.encchspec(&ch);
+ chaninfo = ch.chspec;
--- /dev/null
+From 14fdc2c5318ae420e68496975f48dc1dbef52649 Mon Sep 17 00:00:00 2001
+From: Will Deacon <will.deacon@arm.com>
+Date: Mon, 22 Oct 2018 16:39:01 +0100
+Subject: Documentation/security-bugs: Clarify treatment of embargoed information
+
+From: Will Deacon <will.deacon@arm.com>
+
+commit 14fdc2c5318ae420e68496975f48dc1dbef52649 upstream.
+
+The Linux kernel security team has been accused of rejecting the idea of
+security embargoes. This is incorrect, and could dissuade people from
+reporting security issues to us under the false assumption that the
+issue would leak prematurely.
+
+Clarify the handling of embargoed information in our process
+documentation.
+
+Co-developed-by: Ingo Molnar <mingo@kernel.org>
+Acked-by: Kees Cook <keescook@chromium.org>
+Acked-by: Peter Zijlstra <peterz@infradead.org>
+Acked-by: Laura Abbott <labbott@redhat.com>
+Signed-off-by: Will Deacon <will.deacon@arm.com>
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ Documentation/admin-guide/security-bugs.rst | 45 +++++++++++++++++-----------
+ 1 file changed, 28 insertions(+), 17 deletions(-)
+
+--- a/Documentation/admin-guide/security-bugs.rst
++++ b/Documentation/admin-guide/security-bugs.rst
+@@ -26,23 +26,34 @@ information is helpful. Any exploit cod
+ be released without consent from the reporter unless it has already been
+ made public.
+
+-Disclosure
+-----------
++Disclosure and embargoed information
++------------------------------------
+
+-The goal of the Linux kernel security team is to work with the bug
+-submitter to understand and fix the bug. We prefer to publish the fix as
+-soon as possible, but try to avoid public discussion of the bug itself
+-and leave that to others.
+-
+-Publishing the fix may be delayed when the bug or the fix is not yet
+-fully understood, the solution is not well-tested or for vendor
+-coordination. However, we expect these delays to be short, measurable in
+-days, not weeks or months. A release date is negotiated by the security
+-team working with the bug submitter as well as vendors. However, the
+-kernel security team holds the final say when setting a timeframe. The
+-timeframe varies from immediate (esp. if it's already publicly known bug)
+-to a few weeks. As a basic default policy, we expect report date to
+-release date to be on the order of 7 days.
++The security list is not a disclosure channel. For that, see Coordination
++below.
++
++Once a robust fix has been developed, our preference is to release the
++fix in a timely fashion, treating it no differently than any of the other
++thousands of changes and fixes the Linux kernel project releases every
++month.
++
++However, at the request of the reporter, we will postpone releasing the
++fix for up to 5 business days after the date of the report or after the
++embargo has lifted; whichever comes first. The only exception to that
++rule is if the bug is publicly known, in which case the preference is to
++release the fix as soon as it's available.
++
++Whilst embargoed information may be shared with trusted individuals in
++order to develop a fix, such information will not be published alongside
++the fix or on any other disclosure channel without the permission of the
++reporter. This includes but is not limited to the original bug report
++and followup discussions (if any), exploits, CVE information or the
++identity of the reporter.
++
++In other words our only interest is in getting bugs fixed. All other
++information submitted to the security list and any followup discussions
++of the report are treated confidentially even after the embargo has been
++lifted, in perpetuity.
+
+ Coordination
+ ------------
+@@ -68,7 +79,7 @@ may delay the bug handling. If a reporte
+ assigned ahead of public disclosure, they will need to contact the private
+ linux-distros list, described above. When such a CVE identifier is known
+ before a patch is provided, it is desirable to mention it in the commit
+-message, though.
++message if the reporter agrees.
+
+ Non-disclosure agreements
+ -------------------------
--- /dev/null
+From 544b03da39e2d7b4961d3163976ed4bfb1fac509 Mon Sep 17 00:00:00 2001
+From: Will Deacon <will.deacon@arm.com>
+Date: Mon, 19 Nov 2018 11:07:18 +0000
+Subject: Documentation/security-bugs: Postpone fix publication in exceptional cases
+
+From: Will Deacon <will.deacon@arm.com>
+
+commit 544b03da39e2d7b4961d3163976ed4bfb1fac509 upstream.
+
+At the request of the reporter, the Linux kernel security team offers to
+postpone the publishing of a fix for up to 5 business days from the date
+of a report.
+
+While it is generally undesirable to keep a fix private after it has
+been developed, this short window is intended to allow distributions to
+package the fix into their kernel builds and permits early inclusion of
+the security team in the case of a co-ordinated disclosure with other
+parties. Unfortunately, discussions with major Linux distributions and
+cloud providers has revealed that 5 business days is not sufficient to
+achieve either of these two goals.
+
+As an example, cloud providers need to roll out KVM security fixes to a
+global fleet of hosts with sufficient early ramp-up and monitoring. An
+end-to-end timeline of less than two weeks dramatically cuts into the
+amount of early validation and increases the chance of guest-visible
+regressions.
+
+The consequence of this timeline mismatch is that security issues are
+commonly fixed without the involvement of the Linux kernel security team
+and are instead analysed and addressed by an ad-hoc group of developers
+across companies contributing to Linux. In some cases, mainline (and
+therefore the official stable kernels) can be left to languish for
+extended periods of time. This undermines the Linux kernel security
+process and puts upstream developers in a difficult position should they
+find themselves involved with an undisclosed security problem that they
+are unable to report due to restrictions from their employer.
+
+To accommodate the needs of these users of the Linux kernel and
+encourage them to engage with the Linux security team when security
+issues are first uncovered, extend the maximum period for which fixes
+may be delayed to 7 calendar days, or 14 calendar days in exceptional
+cases, where the logistics of QA and large scale rollouts specifically
+need to be accommodated. This brings parity with the linux-distros@
+maximum embargo period of 14 calendar days.
+
+Cc: Paolo Bonzini <pbonzini@redhat.com>
+Cc: David Woodhouse <dwmw@amazon.co.uk>
+Cc: Amit Shah <aams@amazon.com>
+Cc: Laura Abbott <labbott@redhat.com>
+Acked-by: Kees Cook <keescook@chromium.org>
+Co-developed-by: Thomas Gleixner <tglx@linutronix.de>
+Co-developed-by: David Woodhouse <dwmw@amazon.co.uk>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
+Signed-off-by: Will Deacon <will.deacon@arm.com>
+Reviewed-by: Tyler Hicks <tyhicks@canonical.com>
+Acked-by: Peter Zijlstra <peterz@infradead.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ Documentation/admin-guide/security-bugs.rst | 19 ++++++++++---------
+ 1 file changed, 10 insertions(+), 9 deletions(-)
+
+--- a/Documentation/admin-guide/security-bugs.rst
++++ b/Documentation/admin-guide/security-bugs.rst
+@@ -32,16 +32,17 @@ Disclosure and embargoed information
+ The security list is not a disclosure channel. For that, see Coordination
+ below.
+
+-Once a robust fix has been developed, our preference is to release the
+-fix in a timely fashion, treating it no differently than any of the other
+-thousands of changes and fixes the Linux kernel project releases every
+-month.
++Once a robust fix has been developed, the release process starts. Fixes
++for publicly known bugs are released immediately.
+
+-However, at the request of the reporter, we will postpone releasing the
+-fix for up to 5 business days after the date of the report or after the
+-embargo has lifted; whichever comes first. The only exception to that
+-rule is if the bug is publicly known, in which case the preference is to
+-release the fix as soon as it's available.
++Although our preference is to release fixes for publicly undisclosed bugs
++as soon as they become available, this may be postponed at the request of
++the reporter or an affected party for up to 7 calendar days from the start
++of the release process, with an exceptional extension to 14 calendar days
++if it is agreed that the criticality of the bug requires more time. The
++only valid reason for deferring the publication of a fix is to accommodate
++the logistics of QA and large scale rollouts which require release
++coordination.
+
+ Whilst embargoed information may be shared with trusted individuals in
+ order to develop a fix, such information will not be published alongside
--- /dev/null
+From a05a14049999598a3bb6fab12db6b768a0215522 Mon Sep 17 00:00:00 2001
+From: Vladimir Zapolskiy <vz@mleia.com>
+Date: Fri, 2 Nov 2018 15:39:43 +0200
+Subject: gpio: don't free unallocated ida on gpiochip_add_data_with_key() error path
+
+From: Vladimir Zapolskiy <vz@mleia.com>
+
+commit a05a14049999598a3bb6fab12db6b768a0215522 upstream.
+
+The change corrects the error path in gpiochip_add_data_with_key()
+by avoiding to call ida_simple_remove(), if ida_simple_get() returns
+an error.
+
+Note that ida_simple_remove()/ida_free() throws a BUG(), if id argument
+is negative, it allows to easily check the correctness of the fix by
+fuzzing the return value from ida_simple_get().
+
+Fixes: ff2b13592299 ("gpio: make the gpiochip a real device")
+Cc: stable@vger.kernel.org # v4.6+
+Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpio/gpiolib.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpio/gpiolib.c
++++ b/drivers/gpio/gpiolib.c
+@@ -1285,7 +1285,7 @@ int gpiochip_add_data_with_key(struct gp
+ gdev->descs = kcalloc(chip->ngpio, sizeof(gdev->descs[0]), GFP_KERNEL);
+ if (!gdev->descs) {
+ status = -ENOMEM;
+- goto err_free_gdev;
++ goto err_free_ida;
+ }
+
+ if (chip->ngpio == 0) {
+@@ -1413,8 +1413,9 @@ err_free_label:
+ kfree_const(gdev->label);
+ err_free_descs:
+ kfree(gdev->descs);
+-err_free_gdev:
++err_free_ida:
+ ida_simple_remove(&gpio_ida, gdev->id);
++err_free_gdev:
+ /* failures here can mean systems won't boot... */
+ pr_err("%s: GPIOs %d..%d (%s) failed to register, %d\n", __func__,
+ gdev->base, gdev->base + gdev->ngpio - 1,
--- /dev/null
+From 66e839030fd698586734e017fd55c4f2a89dba0b Mon Sep 17 00:00:00 2001
+From: Matt Chen <matt.chen@intel.com>
+Date: Fri, 3 Aug 2018 14:29:20 +0800
+Subject: iwlwifi: fix wrong WGDS_WIFI_DATA_SIZE
+
+From: Matt Chen <matt.chen@intel.com>
+
+commit 66e839030fd698586734e017fd55c4f2a89dba0b upstream.
+
+From coreboot/BIOS:
+Name ("WGDS", Package() {
+ Revision,
+ Package() {
+ DomainType, // 0x7:WiFi ==> We miss this one.
+ WgdsWiFiSarDeltaGroup1PowerMax1, // Group 1 FCC 2400 Max
+ WgdsWiFiSarDeltaGroup1PowerChainA1, // Group 1 FCC 2400 A Offset
+ WgdsWiFiSarDeltaGroup1PowerChainB1, // Group 1 FCC 2400 B Offset
+ WgdsWiFiSarDeltaGroup1PowerMax2, // Group 1 FCC 5200 Max
+ WgdsWiFiSarDeltaGroup1PowerChainA2, // Group 1 FCC 5200 A Offset
+ WgdsWiFiSarDeltaGroup1PowerChainB2, // Group 1 FCC 5200 B Offset
+ WgdsWiFiSarDeltaGroup2PowerMax1, // Group 2 EC Jap 2400 Max
+ WgdsWiFiSarDeltaGroup2PowerChainA1, // Group 2 EC Jap 2400 A Offset
+ WgdsWiFiSarDeltaGroup2PowerChainB1, // Group 2 EC Jap 2400 B Offset
+ WgdsWiFiSarDeltaGroup2PowerMax2, // Group 2 EC Jap 5200 Max
+ WgdsWiFiSarDeltaGroup2PowerChainA2, // Group 2 EC Jap 5200 A Offset
+ WgdsWiFiSarDeltaGroup2PowerChainB2, // Group 2 EC Jap 5200 B Offset
+ WgdsWiFiSarDeltaGroup3PowerMax1, // Group 3 ROW 2400 Max
+ WgdsWiFiSarDeltaGroup3PowerChainA1, // Group 3 ROW 2400 A Offset
+ WgdsWiFiSarDeltaGroup3PowerChainB1, // Group 3 ROW 2400 B Offset
+ WgdsWiFiSarDeltaGroup3PowerMax2, // Group 3 ROW 5200 Max
+ WgdsWiFiSarDeltaGroup3PowerChainA2, // Group 3 ROW 5200 A Offset
+ WgdsWiFiSarDeltaGroup3PowerChainB2, // Group 3 ROW 5200 B Offset
+ }
+})
+
+When read the ACPI data to find out the WGDS, the DATA_SIZE is never
+matched.
+From the above format, it gives 19 numbers, but our driver is hardcode
+as 18.
+Fix it to pass then can parse the data into our wgds table.
+Then we will see:
+iwlwifi 0000:01:00.0: U iwl_mvm_sar_geo_init Sending GEO_TX_POWER_LIMIT
+iwlwifi 0000:01:00.0: U iwl_mvm_sar_geo_init SAR geographic profile[0]
+Band[0]: chain A = 68 chain B = 69 max_tx_power = 54
+iwlwifi 0000:01:00.0: U iwl_mvm_sar_geo_init SAR geographic profile[0]
+Band[1]: chain A = 48 chain B = 49 max_tx_power = 70
+iwlwifi 0000:01:00.0: U iwl_mvm_sar_geo_init SAR geographic profile[1]
+Band[0]: chain A = 51 chain B = 67 max_tx_power = 50
+iwlwifi 0000:01:00.0: U iwl_mvm_sar_geo_init SAR geographic profile[1]
+Band[1]: chain A = 69 chain B = 70 max_tx_power = 68
+iwlwifi 0000:01:00.0: U iwl_mvm_sar_geo_init SAR geographic profile[2]
+Band[0]: chain A = 49 chain B = 50 max_tx_power = 48
+iwlwifi 0000:01:00.0: U iwl_mvm_sar_geo_init SAR geographic profile[2]
+Band[1]: chain A = 52 chain B = 53 max_tx_power = 51
+
+Cc: stable@vger.kernel.org # 4.12+
+Fixes: a6bff3cb19b7 ("iwlwifi: mvm: add GEO_TX_POWER_LIMIT cmd for geographic tx power table")
+Signed-off-by: Matt Chen <matt.chen@intel.com>
+Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/wireless/intel/iwlwifi/fw/acpi.h | 4 +++-
+ drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 2 +-
+ 2 files changed, 4 insertions(+), 2 deletions(-)
+
+--- a/drivers/net/wireless/intel/iwlwifi/fw/acpi.h
++++ b/drivers/net/wireless/intel/iwlwifi/fw/acpi.h
+@@ -6,6 +6,7 @@
+ * GPL LICENSE SUMMARY
+ *
+ * Copyright(c) 2017 Intel Deutschland GmbH
++ * Copyright(c) 2018 Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+@@ -29,6 +30,7 @@
+ * BSD LICENSE
+ *
+ * Copyright(c) 2017 Intel Deutschland GmbH
++ * Copyright(c) 2018 Intel Corporation
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+@@ -84,7 +86,7 @@
+ #define ACPI_WRDS_WIFI_DATA_SIZE (ACPI_SAR_TABLE_SIZE + 2)
+ #define ACPI_EWRD_WIFI_DATA_SIZE ((ACPI_SAR_PROFILE_NUM - 1) * \
+ ACPI_SAR_TABLE_SIZE + 3)
+-#define ACPI_WGDS_WIFI_DATA_SIZE 18
++#define ACPI_WGDS_WIFI_DATA_SIZE 19
+ #define ACPI_WRDD_WIFI_DATA_SIZE 2
+ #define ACPI_SPLC_WIFI_DATA_SIZE 2
+
+--- a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
++++ b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
+@@ -880,7 +880,7 @@ static int iwl_mvm_sar_geo_init(struct i
+ IWL_DEBUG_RADIO(mvm, "Sending GEO_TX_POWER_LIMIT\n");
+
+ BUILD_BUG_ON(ACPI_NUM_GEO_PROFILES * ACPI_WGDS_NUM_BANDS *
+- ACPI_WGDS_TABLE_SIZE != ACPI_WGDS_WIFI_DATA_SIZE);
++ ACPI_WGDS_TABLE_SIZE + 1 != ACPI_WGDS_WIFI_DATA_SIZE);
+
+ BUILD_BUG_ON(ACPI_NUM_GEO_PROFILES > IWL_NUM_GEO_PROFILES);
+
--- /dev/null
+From 5d041c46ccb9b48acc110e214beff5e2789311df Mon Sep 17 00:00:00 2001
+From: Luca Coelho <luciano.coelho@intel.com>
+Date: Wed, 17 Oct 2018 08:35:15 +0300
+Subject: iwlwifi: mvm: don't use SAR Geo if basic SAR is not used
+
+From: Luca Coelho <luciano.coelho@intel.com>
+
+commit 5d041c46ccb9b48acc110e214beff5e2789311df upstream.
+
+We can't use SAR Geo if basic SAR is not enabled, since the SAR Geo
+tables define offsets in relation to the basic SAR table in use.
+
+To fix this, make iwl_mvm_sar_init() return one in case WRDS is not
+available, so we can skip reading WGDS entirely.
+
+Fixes: a6bff3cb19b7 ("iwlwifi: mvm: add GEO_TX_POWER_LIMIT cmd for geographic tx power table")
+Cc: stable@vger.kernel.org # 4.12+
+Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 36 +++++++++++++++++++++-------
+ 1 file changed, 28 insertions(+), 8 deletions(-)
+
+--- a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
++++ b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
+@@ -915,6 +915,11 @@ static int iwl_mvm_sar_get_ewrd_table(st
+ return -ENOENT;
+ }
+
++static int iwl_mvm_sar_get_wgds_table(struct iwl_mvm *mvm)
++{
++ return -ENOENT;
++}
++
+ static int iwl_mvm_sar_geo_init(struct iwl_mvm *mvm)
+ {
+ return 0;
+@@ -941,8 +946,11 @@ static int iwl_mvm_sar_init(struct iwl_m
+ IWL_DEBUG_RADIO(mvm,
+ "WRDS SAR BIOS table invalid or unavailable. (%d)\n",
+ ret);
+- /* if not available, don't fail and don't bother with EWRD */
+- return 0;
++ /*
++ * If not available, don't fail and don't bother with EWRD.
++ * Return 1 to tell that we can't use WGDS either.
++ */
++ return 1;
+ }
+
+ ret = iwl_mvm_sar_get_ewrd_table(mvm);
+@@ -955,9 +963,13 @@ static int iwl_mvm_sar_init(struct iwl_m
+ /* choose profile 1 (WRDS) as default for both chains */
+ ret = iwl_mvm_sar_select_profile(mvm, 1, 1);
+
+- /* if we don't have profile 0 from BIOS, just skip it */
++ /*
++ * If we don't have profile 0 from BIOS, just skip it. This
++ * means that SAR Geo will not be enabled either, even if we
++ * have other valid profiles.
++ */
+ if (ret == -ENOENT)
+- return 0;
++ return 1;
+
+ return ret;
+ }
+@@ -1155,11 +1167,19 @@ int iwl_mvm_up(struct iwl_mvm *mvm)
+ iwl_mvm_unref(mvm, IWL_MVM_REF_UCODE_DOWN);
+
+ ret = iwl_mvm_sar_init(mvm);
+- if (ret)
+- goto error;
++ if (ret == 0) {
++ ret = iwl_mvm_sar_geo_init(mvm);
++ } else if (ret > 0 && !iwl_mvm_sar_get_wgds_table(mvm)) {
++ /*
++ * If basic SAR is not available, we check for WGDS,
++ * which should *not* be available either. If it is
++ * available, issue an error, because we can't use SAR
++ * Geo without basic SAR.
++ */
++ IWL_ERR(mvm, "BIOS contains WGDS but no WRDS\n");
++ }
+
+- ret = iwl_mvm_sar_geo_init(mvm);
+- if (ret)
++ if (ret < 0)
+ goto error;
+
+ iwl_mvm_leds_sync(mvm);
--- /dev/null
+From 82715ac71e6b94a2c2136e31f3a8e6748e33aa8c Mon Sep 17 00:00:00 2001
+From: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
+Date: Wed, 3 Oct 2018 11:16:54 +0300
+Subject: iwlwifi: mvm: fix regulatory domain update when the firmware starts
+
+From: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
+
+commit 82715ac71e6b94a2c2136e31f3a8e6748e33aa8c upstream.
+
+When the firmware starts, it doesn't have any regulatory
+information, hence it uses the world wide limitations. The
+driver can feed the firmware with previous knowledge that
+was kept in the driver, but the firmware may still not
+update its internal tables.
+
+This happens when we start a BSS interface, and then the
+firmware can change the regulatory tables based on our
+location and it'll use more lenient, location specific
+rules. Then, if the firmware is shut down (when the
+interface is brought down), and then an AP interface is
+created, the firmware will forget the country specific
+rules.
+
+The host will think that we are in a certain country that
+may allow channels and will try to teach the firmware about
+our location, but the firmware may still not allow to drop
+the world wide limitations and apply country specific rules
+because it was just re-started.
+
+In this case, the firmware will reply with MCC_RESP_ILLEGAL
+to the MCC_UPDATE_CMD. In that case, iwlwifi needs to let
+the upper layers (cfg80211 / hostapd) know that the channel
+list they know about has been updated.
+
+This fixes https://bugzilla.kernel.org/show_bug.cgi?id=201105
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
+Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 8 ++++++--
+ drivers/net/wireless/intel/iwlwifi/mvm/nvm.c | 5 ++---
+ 2 files changed, 8 insertions(+), 5 deletions(-)
+
+--- a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
++++ b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
+@@ -306,8 +306,12 @@ struct ieee80211_regdomain *iwl_mvm_get_
+ goto out;
+ }
+
+- if (changed)
+- *changed = (resp->status == MCC_RESP_NEW_CHAN_PROFILE);
++ if (changed) {
++ u32 status = le32_to_cpu(resp->status);
++
++ *changed = (status == MCC_RESP_NEW_CHAN_PROFILE ||
++ status == MCC_RESP_ILLEGAL);
++ }
+
+ regd = iwl_parse_nvm_mcc_info(mvm->trans->dev, mvm->cfg,
+ __le32_to_cpu(resp->n_channels),
+--- a/drivers/net/wireless/intel/iwlwifi/mvm/nvm.c
++++ b/drivers/net/wireless/intel/iwlwifi/mvm/nvm.c
+@@ -545,9 +545,8 @@ iwl_mvm_update_mcc(struct iwl_mvm *mvm,
+ }
+
+ IWL_DEBUG_LAR(mvm,
+- "MCC response status: 0x%x. new MCC: 0x%x ('%c%c') change: %d n_chans: %d\n",
+- status, mcc, mcc >> 8, mcc & 0xff,
+- !!(status == MCC_RESP_NEW_CHAN_PROFILE), n_channels);
++ "MCC response status: 0x%x. new MCC: 0x%x ('%c%c') n_chans: %d\n",
++ status, mcc, mcc >> 8, mcc & 0xff, n_channels);
+
+ exit:
+ iwl_free_resp(&cmd);
--- /dev/null
+From ec484d03ef0df8d34086b95710e355a259cbe1f2 Mon Sep 17 00:00:00 2001
+From: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
+Date: Thu, 16 Aug 2018 13:25:48 +0300
+Subject: iwlwifi: mvm: support sta_statistics() even on older firmware
+
+From: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
+
+commit ec484d03ef0df8d34086b95710e355a259cbe1f2 upstream.
+
+The oldest firmware supported by iwlmvm do support getting
+the average beacon RSSI. Enable the sta_statistics() call
+from mac80211 even on older firmware versions.
+
+Fixes: 33cef9256342 ("iwlwifi: mvm: support beacon statistics for BSS client")
+Cc: stable@vger.kernel.org # 4.2+
+Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
+Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 4 ----
+ 1 file changed, 4 deletions(-)
+
+--- a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
++++ b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
+@@ -4416,10 +4416,6 @@ static void iwl_mvm_mac_sta_statistics(s
+ sinfo->filled |= BIT_ULL(NL80211_STA_INFO_SIGNAL_AVG);
+ }
+
+- if (!fw_has_capa(&mvm->fw->ucode_capa,
+- IWL_UCODE_TLV_CAPA_RADIO_BEACON_STATS))
+- return;
+-
+ /* if beacon filtering isn't on mac80211 does it anyway */
+ if (!(vif->driver_flags & IEEE80211_VIF_BEACON_FILTER))
+ return;
--- /dev/null
+From cb5d21946d2a2f4687c482ab4604af1d29dac35a Mon Sep 17 00:00:00 2001
+From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Date: Thu, 15 Nov 2018 15:03:24 -0800
+Subject: MAINTAINERS: Add Sasha as a stable branch maintainer
+
+From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+commit cb5d21946d2a2f4687c482ab4604af1d29dac35a upstream.
+
+Sasha has somehow been convinced into helping me with the stable kernel
+maintenance. Codify this slip in good judgement before he realizes what
+he really signed up for :)
+
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Acked-by: Sasha Levin <sashal@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ MAINTAINERS | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/MAINTAINERS
++++ b/MAINTAINERS
+@@ -13769,6 +13769,7 @@ F: drivers/i2c/busses/i2c-stm32*
+
+ STABLE BRANCH
+ M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
++M: Sasha Levin <sashal@kernel.org>
+ L: stable@vger.kernel.org
+ S: Supported
+ F: Documentation/process/stable-kernel-rules.rst
--- /dev/null
+From cdcefe6bd9df754f528ffc339d3cc143cea4ddf6 Mon Sep 17 00:00:00 2001
+From: Rajat Jain <rajatja@google.com>
+Date: Mon, 29 Oct 2018 15:17:01 -0700
+Subject: mmc: sdhci-pci: Try "cd" for card-detect lookup before using NULL
+
+From: Rajat Jain <rajatja@google.com>
+
+commit cdcefe6bd9df754f528ffc339d3cc143cea4ddf6 upstream.
+
+Problem:
+
+The card detect IRQ does not work with modern BIOS (that want
+to use _DSD to provide the card detect GPIO to the driver).
+
+Details:
+
+The mmc core provides the mmc_gpiod_request_cd() API to let host drivers
+request the gpio descriptor for the "card detect" pin.
+This pin is specified in the ACPI for the SDHC device:
+
+ * Either as a resource using _CRS. This is a method used by legacy BIOS.
+ (The driver needs to tell which resource index).
+
+ * Or as a named property ("cd-gpios"/"cd-gpio") in _DSD (which internally
+ points to an entry in _CRS). This way, the driver can lookup using a
+ string. This is what modern BIOS prefer to use.
+
+This API finally results in a call to the following code:
+
+struct gpio_desc *acpi_find_gpio(..., const char *con_id,...)
+{
+...
+ /* Lookup gpio (using "<con_id>-gpio") in the _DSD */
+...
+ if (!acpi_can_fallback_to_crs(adev, con_id))
+ return ERR_PTR(-ENOENT);
+...
+ /* Falling back to _CRS is allowed, Lookup gpio in the _CRS */
+...
+}
+
+Note that this means that if the ACPI has _DSD properties, the kernel
+will never use _CRS for the lookup (Because acpi_can_fallback_to_crs()
+will always be false for any device hat has _DSD entries).
+
+The SDHCI driver is thus currently broken on a modern BIOS, even if
+BIOS provides both _CRS (for index based lookup) and _DSD entries (for
+string based lookup). Ironically, none of these will be used for the
+lookup currently because:
+
+* Since the con_id is NULL, acpi_find_gpio() does not find a matching
+ entry in DSDT. (The _DSDT entry has the property name = "cd-gpios")
+
+* Because ACPI contains DSDT entries, thus acpi_can_fallback_to_crs()
+ returns false (because device properties have been populated from
+ _DSD), thus the _CRS is never used for the lookup.
+
+Fix:
+
+Try "cd" for lookup in the _DSD before falling back to using NULL so
+as to try looking up in the _CRS.
+
+I've tested this patch successfully with both Legacy BIOS (that
+provide only _CRS method) as well as modern BIOS (that provide both
+_CRS and _DSD). Also the use of "cd" appears to be fairly consistent
+across other users of this API (other MMC host controller drivers).
+
+Link: https://lkml.org/lkml/2018/9/25/1113
+Signed-off-by: Rajat Jain <rajatja@google.com>
+Acked-by: Adrian Hunter <adrian.hunter@intel.com>
+Fixes: f10e4bf6632b ("gpio: acpi: Even more tighten up ACPI GPIO lookups")
+Cc: stable@vger.kernel.org
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/host/sdhci-pci-core.c | 7 ++++++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+--- a/drivers/mmc/host/sdhci-pci-core.c
++++ b/drivers/mmc/host/sdhci-pci-core.c
+@@ -1762,8 +1762,13 @@ static struct sdhci_pci_slot *sdhci_pci_
+ device_init_wakeup(&pdev->dev, true);
+
+ if (slot->cd_idx >= 0) {
+- ret = mmc_gpiod_request_cd(host->mmc, NULL, slot->cd_idx,
++ ret = mmc_gpiod_request_cd(host->mmc, "cd", slot->cd_idx,
+ slot->cd_override_level, 0, NULL);
++ if (ret && ret != -EPROBE_DEFER)
++ ret = mmc_gpiod_request_cd(host->mmc, NULL,
++ slot->cd_idx,
++ slot->cd_override_level,
++ 0, NULL);
+ if (ret == -EPROBE_DEFER)
+ goto remove;
+
--- /dev/null
+From 5305ec6a27b2dc7398a689e661a4a2e951026f09 Mon Sep 17 00:00:00 2001
+From: Adrian Hunter <adrian.hunter@intel.com>
+Date: Mon, 19 Nov 2018 14:53:07 +0200
+Subject: mmc: sdhci-pci: Workaround GLK firmware failing to restore the tuning value
+
+From: Adrian Hunter <adrian.hunter@intel.com>
+
+commit 5305ec6a27b2dc7398a689e661a4a2e951026f09 upstream.
+
+GLK firmware can indicate that the tuning value will be restored after
+runtime suspend, but not actually do that. Add a workaround that detects
+such cases, and lets the driver do re-tuning instead.
+
+Reported-by: Anisse Astier <anisse@astier.eu>
+Tested-by: Anisse Astier <anisse@astier.eu>
+Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/host/sdhci-pci-core.c | 79 +++++++++++++++++++++++++++++++++++++-
+ 1 file changed, 77 insertions(+), 2 deletions(-)
+
+--- a/drivers/mmc/host/sdhci-pci-core.c
++++ b/drivers/mmc/host/sdhci-pci-core.c
+@@ -12,6 +12,7 @@
+ * - JMicron (hardware and technical support)
+ */
+
++#include <linux/bitfield.h>
+ #include <linux/string.h>
+ #include <linux/delay.h>
+ #include <linux/highmem.h>
+@@ -462,6 +463,9 @@ struct intel_host {
+ u32 dsm_fns;
+ int drv_strength;
+ bool d3_retune;
++ bool rpm_retune_ok;
++ u32 glk_rx_ctrl1;
++ u32 glk_tun_val;
+ };
+
+ static const guid_t intel_dsm_guid =
+@@ -791,6 +795,77 @@ cleanup:
+ return ret;
+ }
+
++#ifdef CONFIG_PM
++#define GLK_RX_CTRL1 0x834
++#define GLK_TUN_VAL 0x840
++#define GLK_PATH_PLL GENMASK(13, 8)
++#define GLK_DLY GENMASK(6, 0)
++/* Workaround firmware failing to restore the tuning value */
++static void glk_rpm_retune_wa(struct sdhci_pci_chip *chip, bool susp)
++{
++ struct sdhci_pci_slot *slot = chip->slots[0];
++ struct intel_host *intel_host = sdhci_pci_priv(slot);
++ struct sdhci_host *host = slot->host;
++ u32 glk_rx_ctrl1;
++ u32 glk_tun_val;
++ u32 dly;
++
++ if (intel_host->rpm_retune_ok || !mmc_can_retune(host->mmc))
++ return;
++
++ glk_rx_ctrl1 = sdhci_readl(host, GLK_RX_CTRL1);
++ glk_tun_val = sdhci_readl(host, GLK_TUN_VAL);
++
++ if (susp) {
++ intel_host->glk_rx_ctrl1 = glk_rx_ctrl1;
++ intel_host->glk_tun_val = glk_tun_val;
++ return;
++ }
++
++ if (!intel_host->glk_tun_val)
++ return;
++
++ if (glk_rx_ctrl1 != intel_host->glk_rx_ctrl1) {
++ intel_host->rpm_retune_ok = true;
++ return;
++ }
++
++ dly = FIELD_PREP(GLK_DLY, FIELD_GET(GLK_PATH_PLL, glk_rx_ctrl1) +
++ (intel_host->glk_tun_val << 1));
++ if (dly == FIELD_GET(GLK_DLY, glk_rx_ctrl1))
++ return;
++
++ glk_rx_ctrl1 = (glk_rx_ctrl1 & ~GLK_DLY) | dly;
++ sdhci_writel(host, glk_rx_ctrl1, GLK_RX_CTRL1);
++
++ intel_host->rpm_retune_ok = true;
++ chip->rpm_retune = true;
++ mmc_retune_needed(host->mmc);
++ pr_info("%s: Requiring re-tune after rpm resume", mmc_hostname(host->mmc));
++}
++
++static void glk_rpm_retune_chk(struct sdhci_pci_chip *chip, bool susp)
++{
++ if (chip->pdev->device == PCI_DEVICE_ID_INTEL_GLK_EMMC &&
++ !chip->rpm_retune)
++ glk_rpm_retune_wa(chip, susp);
++}
++
++static int glk_runtime_suspend(struct sdhci_pci_chip *chip)
++{
++ glk_rpm_retune_chk(chip, true);
++
++ return sdhci_cqhci_runtime_suspend(chip);
++}
++
++static int glk_runtime_resume(struct sdhci_pci_chip *chip)
++{
++ glk_rpm_retune_chk(chip, false);
++
++ return sdhci_cqhci_runtime_resume(chip);
++}
++#endif
++
+ #ifdef CONFIG_ACPI
+ static int ni_set_max_freq(struct sdhci_pci_slot *slot)
+ {
+@@ -879,8 +954,8 @@ static const struct sdhci_pci_fixes sdhc
+ .resume = sdhci_cqhci_resume,
+ #endif
+ #ifdef CONFIG_PM
+- .runtime_suspend = sdhci_cqhci_runtime_suspend,
+- .runtime_resume = sdhci_cqhci_runtime_resume,
++ .runtime_suspend = glk_runtime_suspend,
++ .runtime_resume = glk_runtime_resume,
+ #endif
+ .quirks = SDHCI_QUIRK_NO_ENDATTR_IN_NOPDESC,
+ .quirks2 = SDHCI_QUIRK2_PRESET_VALUE_BROKEN |
--- /dev/null
+From 622fecbccfe86a8052dea6b512d3821dcce29994 Mon Sep 17 00:00:00 2001
+From: Keerthy <j-keerthy@ti.com>
+Date: Wed, 7 Nov 2018 10:04:23 +0530
+Subject: opp: ti-opp-supply: Correct the supply in _get_optimal_vdd_voltage call
+
+From: Keerthy <j-keerthy@ti.com>
+
+commit 622fecbccfe86a8052dea6b512d3821dcce29994 upstream.
+
+_get_optimal_vdd_voltage call provides new_supply_vbb->u_volt
+as the reference voltage while it should be really new_supply_vdd->u_volt.
+
+Cc: 4.16+ <stable@vger.kernel.org> # v4.16+
+Fixes: 9a835fa6e47 ("PM / OPP: Add ti-opp-supply driver")
+Signed-off-by: Keerthy <j-keerthy@ti.com>
+Acked-by: Dave Gerlach <d-gerlach@ti.com>
+Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/opp/ti-opp-supply.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/opp/ti-opp-supply.c
++++ b/drivers/opp/ti-opp-supply.c
+@@ -288,7 +288,7 @@ static int ti_opp_supply_set_opp(struct
+ int ret;
+
+ vdd_uv = _get_optimal_vdd_voltage(dev, &opp_data,
+- new_supply_vbb->u_volt);
++ new_supply_vdd->u_volt);
+
+ if (new_supply_vdd->u_volt_min < vdd_uv)
+ new_supply_vdd->u_volt_min = vdd_uv;
--- /dev/null
+From ba038546ff9e15d54d1134b5c5d2355648c00dec Mon Sep 17 00:00:00 2001
+From: Keerthy <j-keerthy@ti.com>
+Date: Wed, 7 Nov 2018 10:04:22 +0530
+Subject: opp: ti-opp-supply: Dynamically update u_volt_min
+
+From: Keerthy <j-keerthy@ti.com>
+
+commit ba038546ff9e15d54d1134b5c5d2355648c00dec upstream.
+
+The voltage range (min, max) provided in the device tree is from
+the data manual and is pretty big, catering to a wide range of devices.
+On a i2c read/write failure the regulator_set_voltage_triplet function
+falls back to set voltage between min and max. The min value from Device
+Tree can be lesser than the optimal value and in that case that can lead
+to a hang or crash. Hence set the u_volt_min dynamically to the optimal
+voltage value.
+
+Cc: 4.16+ <stable@vger.kernel.org> # v4.16+
+Fixes: 9a835fa6e47 ("PM / OPP: Add ti-opp-supply driver")
+Signed-off-by: Keerthy <j-keerthy@ti.com>
+Acked-by: Dave Gerlach <d-gerlach@ti.com>
+Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/opp/ti-opp-supply.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/opp/ti-opp-supply.c
++++ b/drivers/opp/ti-opp-supply.c
+@@ -290,6 +290,9 @@ static int ti_opp_supply_set_opp(struct
+ vdd_uv = _get_optimal_vdd_voltage(dev, &opp_data,
+ new_supply_vbb->u_volt);
+
++ if (new_supply_vdd->u_volt_min < vdd_uv)
++ new_supply_vdd->u_volt_min = vdd_uv;
++
+ /* Scaling up? Scale voltage before frequency */
+ if (freq > old_freq) {
+ ret = _opp_set_voltage(dev, new_supply_vdd, vdd_uv, vdd_reg,
hid-steam-remove-input-device-when-a-hid-client-is-running.patch
efi-libstub-arm-support-building-with-clang.patch
+usb-core-fix-hub-port-connection-events-lost.patch
+usb-dwc3-gadget-fix-isoc-trb-type-on-unaligned-transfers.patch
+usb-dwc3-gadget-properly-check-last-unaligned-zero-chain-trb.patch
+usb-dwc3-core-clean-up-ulpi-device.patch
+usb-dwc3-fix-null-pointer-exception-in-dwc3_pci_remove.patch
+xhci-fix-leaking-usb3-shared_hcd-at-xhci-removal.patch
+xhci-handle-port-status-events-for-removed-usb3-hcd.patch
+xhci-add-check-for-invalid-byte-size-error-when-uas-devices-are-connected.patch
+usb-xhci-fix-uninitialized-completion-when-usb3-port-got-wrong-status.patch
+usb-xhci-fix-timeout-for-transition-from-rexit-to-u0.patch
+xhci-add-quirk-to-workaround-the-errata-seen-on-cavium-thunder-x2-soc.patch
+usb-xhci-prevent-bus-suspend-if-a-port-connect-change-or-polling-state-is-detected.patch
+alsa-oss-use-kvzalloc-for-local-buffer-allocations.patch
+maintainers-add-sasha-as-a-stable-branch-maintainer.patch
+documentation-security-bugs-clarify-treatment-of-embargoed-information.patch
+documentation-security-bugs-postpone-fix-publication-in-exceptional-cases.patch
+mmc-sdhci-pci-try-cd-for-card-detect-lookup-before-using-null.patch
+mmc-sdhci-pci-workaround-glk-firmware-failing-to-restore-the-tuning-value.patch
+gpio-don-t-free-unallocated-ida-on-gpiochip_add_data_with_key-error-path.patch
+iwlwifi-fix-wrong-wgds_wifi_data_size.patch
+iwlwifi-mvm-support-sta_statistics-even-on-older-firmware.patch
+iwlwifi-mvm-fix-regulatory-domain-update-when-the-firmware-starts.patch
+iwlwifi-mvm-don-t-use-sar-geo-if-basic-sar-is-not-used.patch
+brcmfmac-fix-reporting-support-for-160-mhz-channels.patch
+opp-ti-opp-supply-dynamically-update-u_volt_min.patch
+opp-ti-opp-supply-correct-the-supply-in-_get_optimal_vdd_voltage-call.patch
+tools-power-cpupower-fix-compilation-with-static-true.patch
--- /dev/null
+From 9de9aa45e9bd67232e000cca42ceb134b8ae51b6 Mon Sep 17 00:00:00 2001
+From: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
+Date: Tue, 16 Oct 2018 11:56:26 +0300
+Subject: tools/power/cpupower: fix compilation with STATIC=true
+
+From: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
+
+commit 9de9aa45e9bd67232e000cca42ceb134b8ae51b6 upstream.
+
+Rename duplicate sysfs_read_file into cpupower_read_sysfs and fix linking.
+
+Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
+Acked-by: Thomas Renninger <trenn@suse.de>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Shuah Khan (Samsung OSG) <shuah@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ tools/power/cpupower/bench/Makefile | 2 +-
+ tools/power/cpupower/lib/cpufreq.c | 2 +-
+ tools/power/cpupower/lib/cpuidle.c | 2 +-
+ tools/power/cpupower/lib/cpupower.c | 4 ++--
+ tools/power/cpupower/lib/cpupower_intern.h | 2 +-
+ 5 files changed, 6 insertions(+), 6 deletions(-)
+
+--- a/tools/power/cpupower/bench/Makefile
++++ b/tools/power/cpupower/bench/Makefile
+@@ -9,7 +9,7 @@ endif
+ ifeq ($(strip $(STATIC)),true)
+ LIBS = -L../ -L$(OUTPUT) -lm
+ OBJS = $(OUTPUT)main.o $(OUTPUT)parse.o $(OUTPUT)system.o $(OUTPUT)benchmark.o \
+- $(OUTPUT)../lib/cpufreq.o $(OUTPUT)../lib/sysfs.o
++ $(OUTPUT)../lib/cpufreq.o $(OUTPUT)../lib/cpupower.o
+ else
+ LIBS = -L../ -L$(OUTPUT) -lm -lcpupower
+ OBJS = $(OUTPUT)main.o $(OUTPUT)parse.o $(OUTPUT)system.o $(OUTPUT)benchmark.o
+--- a/tools/power/cpupower/lib/cpufreq.c
++++ b/tools/power/cpupower/lib/cpufreq.c
+@@ -28,7 +28,7 @@ static unsigned int sysfs_cpufreq_read_f
+
+ snprintf(path, sizeof(path), PATH_TO_CPU "cpu%u/cpufreq/%s",
+ cpu, fname);
+- return sysfs_read_file(path, buf, buflen);
++ return cpupower_read_sysfs(path, buf, buflen);
+ }
+
+ /* helper function to write a new value to a /sys file */
+--- a/tools/power/cpupower/lib/cpuidle.c
++++ b/tools/power/cpupower/lib/cpuidle.c
+@@ -319,7 +319,7 @@ static unsigned int sysfs_cpuidle_read_f
+
+ snprintf(path, sizeof(path), PATH_TO_CPU "cpuidle/%s", fname);
+
+- return sysfs_read_file(path, buf, buflen);
++ return cpupower_read_sysfs(path, buf, buflen);
+ }
+
+
+--- a/tools/power/cpupower/lib/cpupower.c
++++ b/tools/power/cpupower/lib/cpupower.c
+@@ -15,7 +15,7 @@
+ #include "cpupower.h"
+ #include "cpupower_intern.h"
+
+-unsigned int sysfs_read_file(const char *path, char *buf, size_t buflen)
++unsigned int cpupower_read_sysfs(const char *path, char *buf, size_t buflen)
+ {
+ int fd;
+ ssize_t numread;
+@@ -95,7 +95,7 @@ static int sysfs_topology_read_file(unsi
+
+ snprintf(path, sizeof(path), PATH_TO_CPU "cpu%u/topology/%s",
+ cpu, fname);
+- if (sysfs_read_file(path, linebuf, MAX_LINE_LEN) == 0)
++ if (cpupower_read_sysfs(path, linebuf, MAX_LINE_LEN) == 0)
+ return -1;
+ *result = strtol(linebuf, &endp, 0);
+ if (endp == linebuf || errno == ERANGE)
+--- a/tools/power/cpupower/lib/cpupower_intern.h
++++ b/tools/power/cpupower/lib/cpupower_intern.h
+@@ -3,4 +3,4 @@
+ #define MAX_LINE_LEN 4096
+ #define SYSFS_PATH_MAX 255
+
+-unsigned int sysfs_read_file(const char *path, char *buf, size_t buflen);
++unsigned int cpupower_read_sysfs(const char *path, char *buf, size_t buflen);
--- /dev/null
+From 22454b79e6de05fa61a2a72d00d2eed798abbb75 Mon Sep 17 00:00:00 2001
+From: Dennis Wassenberg <dennis.wassenberg@secunet.com>
+Date: Tue, 13 Nov 2018 14:40:34 +0100
+Subject: usb: core: Fix hub port connection events lost
+
+From: Dennis Wassenberg <dennis.wassenberg@secunet.com>
+
+commit 22454b79e6de05fa61a2a72d00d2eed798abbb75 upstream.
+
+This will clear the USB_PORT_FEAT_C_CONNECTION bit in case of a hub port reset
+only if a device is was attached to the hub port before resetting the hub port.
+
+Using a Lenovo T480s attached to the ultra dock it was not possible to detect
+some usb-c devices at the dock usb-c ports because the hub_port_reset code
+will clear the USB_PORT_FEAT_C_CONNECTION bit after the actual hub port reset.
+Using this device combo the USB_PORT_FEAT_C_CONNECTION bit was set between the
+actual hub port reset and the clear of the USB_PORT_FEAT_C_CONNECTION bit.
+This ends up with clearing the USB_PORT_FEAT_C_CONNECTION bit after the
+new device was attached such that it was not detected.
+
+This patch will not clear the USB_PORT_FEAT_C_CONNECTION bit if there is
+currently no device attached to the port before the hub port reset.
+This will avoid clearing the connection bit for new attached devices.
+
+Signed-off-by: Dennis Wassenberg <dennis.wassenberg@secunet.com>
+Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com>
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/core/hub.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/usb/core/hub.c
++++ b/drivers/usb/core/hub.c
+@@ -2847,7 +2847,9 @@ static int hub_port_reset(struct usb_hub
+ USB_PORT_FEAT_C_BH_PORT_RESET);
+ usb_clear_port_feature(hub->hdev, port1,
+ USB_PORT_FEAT_C_PORT_LINK_STATE);
+- usb_clear_port_feature(hub->hdev, port1,
++
++ if (udev)
++ usb_clear_port_feature(hub->hdev, port1,
+ USB_PORT_FEAT_C_CONNECTION);
+
+ /*
--- /dev/null
+From 08fd9a82fda86529bb2f2af3c2f7cb657b4d3066 Mon Sep 17 00:00:00 2001
+From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Date: Mon, 27 Aug 2018 18:30:16 +0300
+Subject: usb: dwc3: core: Clean up ULPI device
+
+From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+
+commit 08fd9a82fda86529bb2f2af3c2f7cb657b4d3066 upstream.
+
+If dwc3_core_init_mode() fails with deferred probe,
+next probe fails on sysfs with
+
+sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:11.0/dwc3.0.auto/dwc3.0.auto.ulpi'
+
+To avoid this failure, clean up ULPI device.
+
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/dwc3/core.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/usb/dwc3/core.c
++++ b/drivers/usb/dwc3/core.c
+@@ -1499,6 +1499,7 @@ static int dwc3_probe(struct platform_de
+
+ err5:
+ dwc3_event_buffers_cleanup(dwc);
++ dwc3_ulpi_exit(dwc);
+
+ err4:
+ dwc3_free_scratch_buffers(dwc);
--- /dev/null
+From 7b412b04a0c7000293008231ce8413056abb1982 Mon Sep 17 00:00:00 2001
+From: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
+Date: Wed, 17 Oct 2018 11:40:26 -0700
+Subject: usb: dwc3: Fix NULL pointer exception in dwc3_pci_remove()
+
+From: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
+
+commit 7b412b04a0c7000293008231ce8413056abb1982 upstream.
+
+In dwc3_pci_quirks() function, gpiod lookup table is only registered for
+baytrail SOC. But in dwc3_pci_remove(), we try to unregistered it
+without any checks. This leads to NULL pointer de-reference exception in
+gpiod_remove_lookup_table() when unloading the module for non baytrail
+SOCs. This patch fixes this issue.
+
+Fixes: 5741022cbdf3 ("usb: dwc3: pci: Add GPIO lookup table on platforms
+without ACPI GPIO resources")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
+Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
+Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/dwc3/dwc3-pci.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/usb/dwc3/dwc3-pci.c
++++ b/drivers/usb/dwc3/dwc3-pci.c
+@@ -283,8 +283,10 @@ err:
+ static void dwc3_pci_remove(struct pci_dev *pci)
+ {
+ struct dwc3_pci *dwc = pci_get_drvdata(pci);
++ struct pci_dev *pdev = dwc->pci;
+
+- gpiod_remove_lookup_table(&platform_bytcr_gpios);
++ if (pdev->device == PCI_DEVICE_ID_INTEL_BYT)
++ gpiod_remove_lookup_table(&platform_bytcr_gpios);
+ #ifdef CONFIG_PM
+ cancel_work_sync(&dwc->wakeup_work);
+ #endif
--- /dev/null
+From 2fc6d4be35fb1e262f209758e25bfe2b7a113a7f Mon Sep 17 00:00:00 2001
+From: Felipe Balbi <felipe.balbi@linux.intel.com>
+Date: Wed, 1 Aug 2018 09:37:34 +0300
+Subject: usb: dwc3: gadget: fix ISOC TRB type on unaligned transfers
+
+From: Felipe Balbi <felipe.balbi@linux.intel.com>
+
+commit 2fc6d4be35fb1e262f209758e25bfe2b7a113a7f upstream.
+
+When chaining ISOC TRBs together, only the first ISOC TRB should be of
+type ISOC_FIRST, all others should be of type ISOC. This patch fixes
+that.
+
+Fixes: c6267a51639b ("usb: dwc3: gadget: align transfers to wMaxPacketSize")
+Cc: <stable@vger.kernel.org> # v4.11+
+Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/dwc3/gadget.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/usb/dwc3/gadget.c
++++ b/drivers/usb/dwc3/gadget.c
+@@ -1072,7 +1072,7 @@ static void dwc3_prepare_one_trb_sg(stru
+ /* Now prepare one extra TRB to align transfer size */
+ trb = &dep->trb_pool[dep->trb_enqueue];
+ __dwc3_prepare_one_trb(dep, trb, dwc->bounce_addr,
+- maxp - rem, false, 0,
++ maxp - rem, false, 1,
+ req->request.stream_id,
+ req->request.short_not_ok,
+ req->request.no_interrupt);
+@@ -1116,7 +1116,7 @@ static void dwc3_prepare_one_trb_linear(
+ /* Now prepare one extra TRB to align transfer size */
+ trb = &dep->trb_pool[dep->trb_enqueue];
+ __dwc3_prepare_one_trb(dep, trb, dwc->bounce_addr, maxp - rem,
+- false, 0, req->request.stream_id,
++ false, 1, req->request.stream_id,
+ req->request.short_not_ok,
+ req->request.no_interrupt);
+ } else if (req->request.zero && req->request.length &&
+@@ -1132,7 +1132,7 @@ static void dwc3_prepare_one_trb_linear(
+ /* Now prepare one extra TRB to handle ZLP */
+ trb = &dep->trb_pool[dep->trb_enqueue];
+ __dwc3_prepare_one_trb(dep, trb, dwc->bounce_addr, 0,
+- false, 0, req->request.stream_id,
++ false, 1, req->request.stream_id,
+ req->request.short_not_ok,
+ req->request.no_interrupt);
+ } else {
--- /dev/null
+From ba3a51ac32ebcf8d0a54b37f1af268ad8a31c52f Mon Sep 17 00:00:00 2001
+From: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
+Date: Thu, 2 Aug 2018 20:17:16 -0700
+Subject: usb: dwc3: gadget: Properly check last unaligned/zero chain TRB
+
+From: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
+
+commit ba3a51ac32ebcf8d0a54b37f1af268ad8a31c52f upstream.
+
+Current check for the last extra TRB for zero and unaligned transfers
+does not account for isoc OUT. The last TRB of the Buffer Descriptor for
+isoc OUT transfers will be retired with HWO=0. As a result, we won't
+return early. The req->remaining will be updated to include the BUFSIZ
+count of the extra TRB, and the actual number of transferred bytes
+calculation will be wrong.
+
+To fix this, check whether it's a short or zero packet and the last TRB
+chain bit to return early.
+
+Fixes: c6267a51639b ("usb: dwc3: gadget: align transfers to wMaxPacketSize")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
+Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/dwc3/gadget.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/usb/dwc3/gadget.c
++++ b/drivers/usb/dwc3/gadget.c
+@@ -2250,7 +2250,7 @@ static int dwc3_gadget_ep_reclaim_comple
+ * with one TRB pending in the ring. We need to manually clear HWO bit
+ * from that TRB.
+ */
+- if ((req->zero || req->unaligned) && (trb->ctrl & DWC3_TRB_CTRL_HWO)) {
++ if ((req->zero || req->unaligned) && !(trb->ctrl & DWC3_TRB_CTRL_CHN)) {
+ trb->ctrl &= ~DWC3_TRB_CTRL_HWO;
+ return 1;
+ }
--- /dev/null
+From a5baeaeabcca3244782a9b6382ebab6f8a58f583 Mon Sep 17 00:00:00 2001
+From: Aaron Ma <aaron.ma@canonical.com>
+Date: Fri, 9 Nov 2018 17:21:21 +0200
+Subject: usb: xhci: fix timeout for transition from RExit to U0
+
+From: Aaron Ma <aaron.ma@canonical.com>
+
+commit a5baeaeabcca3244782a9b6382ebab6f8a58f583 upstream.
+
+This definition is used by msecs_to_jiffies in milliseconds.
+According to the comments, max rexit timeout should be 20ms.
+Align with the comments to properly calculate the delay.
+
+Verified on Sunrise Point-LP and Cannon Lake.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Aaron Ma <aaron.ma@canonical.com>
+Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/host/xhci-hub.c | 4 ++--
+ drivers/usb/host/xhci.h | 2 +-
+ 2 files changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/usb/host/xhci-hub.c
++++ b/drivers/usb/host/xhci-hub.c
+@@ -921,7 +921,7 @@ static u32 xhci_get_port_status(struct u
+ time_left = wait_for_completion_timeout(
+ &bus_state->rexit_done[wIndex],
+ msecs_to_jiffies(
+- XHCI_MAX_REXIT_TIMEOUT));
++ XHCI_MAX_REXIT_TIMEOUT_MS));
+ spin_lock_irqsave(&xhci->lock, flags);
+
+ if (time_left) {
+@@ -935,7 +935,7 @@ static u32 xhci_get_port_status(struct u
+ } else {
+ int port_status = readl(port->addr);
+ xhci_warn(xhci, "Port resume took longer than %i msec, port status = 0x%x\n",
+- XHCI_MAX_REXIT_TIMEOUT,
++ XHCI_MAX_REXIT_TIMEOUT_MS,
+ port_status);
+ status |= USB_PORT_STAT_SUSPEND;
+ clear_bit(wIndex, &bus_state->rexit_ports);
+--- a/drivers/usb/host/xhci.h
++++ b/drivers/usb/host/xhci.h
+@@ -1678,7 +1678,7 @@ struct xhci_bus_state {
+ * It can take up to 20 ms to transition from RExit to U0 on the
+ * Intel Lynx Point LP xHCI host.
+ */
+-#define XHCI_MAX_REXIT_TIMEOUT (20 * 1000)
++#define XHCI_MAX_REXIT_TIMEOUT_MS 20
+
+ static inline unsigned int hcd_index(struct usb_hcd *hcd)
+ {
--- /dev/null
+From 958c0bd86075d4ef1c936998deefe1947e539240 Mon Sep 17 00:00:00 2001
+From: Aaron Ma <aaron.ma@canonical.com>
+Date: Fri, 9 Nov 2018 17:21:20 +0200
+Subject: usb: xhci: fix uninitialized completion when USB3 port got wrong status
+
+From: Aaron Ma <aaron.ma@canonical.com>
+
+commit 958c0bd86075d4ef1c936998deefe1947e539240 upstream.
+
+Realtek USB3.0 Card Reader [0bda:0328] reports wrong port status on
+Cannon lake PCH USB3.1 xHCI [8086:a36d] after resume from S3,
+after clear port reset it works fine.
+
+Since this device is registered on USB3 roothub at boot,
+when port status reports not superspeed, xhci_get_port_status will call
+an uninitialized completion in bus_state[0].
+Kernel will hang because of NULL pointer.
+
+Restrict the USB2 resume status check in USB2 roothub to fix hang issue.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Aaron Ma <aaron.ma@canonical.com>
+Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/host/xhci-hub.c | 2 +-
+ drivers/usb/host/xhci-ring.c | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/usb/host/xhci-hub.c
++++ b/drivers/usb/host/xhci-hub.c
+@@ -876,7 +876,7 @@ static u32 xhci_get_port_status(struct u
+ status |= USB_PORT_STAT_SUSPEND;
+ }
+ if ((raw_port_status & PORT_PLS_MASK) == XDEV_RESUME &&
+- !DEV_SUPERSPEED_ANY(raw_port_status)) {
++ !DEV_SUPERSPEED_ANY(raw_port_status) && hcd->speed < HCD_USB3) {
+ if ((raw_port_status & PORT_RESET) ||
+ !(raw_port_status & PORT_PE))
+ return 0xffffffff;
+--- a/drivers/usb/host/xhci-ring.c
++++ b/drivers/usb/host/xhci-ring.c
+@@ -1642,7 +1642,7 @@ static void handle_port_status(struct xh
+ * RExit to a disconnect state). If so, let the the driver know it's
+ * out of the RExit state.
+ */
+- if (!DEV_SUPERSPEED_ANY(portsc) &&
++ if (!DEV_SUPERSPEED_ANY(portsc) && hcd->speed < HCD_USB3 &&
+ test_and_clear_bit(hcd_portnum,
+ &bus_state->rexit_ports)) {
+ complete(&bus_state->rexit_done[hcd_portnum]);
--- /dev/null
+From 2f31a67f01a8beb22cae754c53522cb61a005750 Mon Sep 17 00:00:00 2001
+From: Mathias Nyman <mathias.nyman@linux.intel.com>
+Date: Thu, 15 Nov 2018 11:38:41 +0200
+Subject: usb: xhci: Prevent bus suspend if a port connect change or polling state is detected
+
+From: Mathias Nyman <mathias.nyman@linux.intel.com>
+
+commit 2f31a67f01a8beb22cae754c53522cb61a005750 upstream.
+
+USB3 roothub might autosuspend before a plugged USB3 device is detected,
+causing USB3 device enumeration failure.
+
+USB3 devices don't show up as connected and enabled until USB3 link trainig
+completes. On a fast booting platform with a slow USB3 link training the
+link might reach the connected enabled state just as the bus is suspending.
+
+If this device is discovered first time by the xhci_bus_suspend() routine
+it will be put to U3 suspended state like the other ports which failed to
+suspend earlier.
+
+The hub thread will notice the connect change and resume the bus,
+moving the port back to U0
+
+This U0 -> U3 -> U0 transition right after being connected seems to be
+too much for some devices, causing them to first go to SS.Inactive state,
+and finally end up stuck in a polling state with reset asserted
+
+Fix this by failing the bus suspend if a port has a connect change or is
+in a polling state in xhci_bus_suspend().
+
+Don't do any port changes until all ports are checked, buffer all port
+changes and only write them in the end if suspend can proceed
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/host/xhci-hub.c | 60 +++++++++++++++++++++++++++++++++-----------
+ 1 file changed, 46 insertions(+), 14 deletions(-)
+
+--- a/drivers/usb/host/xhci-hub.c
++++ b/drivers/usb/host/xhci-hub.c
+@@ -1474,15 +1474,18 @@ int xhci_bus_suspend(struct usb_hcd *hcd
+ unsigned long flags;
+ struct xhci_hub *rhub;
+ struct xhci_port **ports;
++ u32 portsc_buf[USB_MAXCHILDREN];
++ bool wake_enabled;
+
+ rhub = xhci_get_rhub(hcd);
+ ports = rhub->ports;
+ max_ports = rhub->num_ports;
+ bus_state = &xhci->bus_state[hcd_index(hcd)];
++ wake_enabled = hcd->self.root_hub->do_remote_wakeup;
+
+ spin_lock_irqsave(&xhci->lock, flags);
+
+- if (hcd->self.root_hub->do_remote_wakeup) {
++ if (wake_enabled) {
+ if (bus_state->resuming_ports || /* USB2 */
+ bus_state->port_remote_wakeup) { /* USB3 */
+ spin_unlock_irqrestore(&xhci->lock, flags);
+@@ -1490,26 +1493,36 @@ int xhci_bus_suspend(struct usb_hcd *hcd
+ return -EBUSY;
+ }
+ }
+-
+- port_index = max_ports;
++ /*
++ * Prepare ports for suspend, but don't write anything before all ports
++ * are checked and we know bus suspend can proceed
++ */
+ bus_state->bus_suspended = 0;
++ port_index = max_ports;
+ while (port_index--) {
+- /* suspend the port if the port is not suspended */
+ u32 t1, t2;
+- int slot_id;
+
+ t1 = readl(ports[port_index]->addr);
+ t2 = xhci_port_state_to_neutral(t1);
++ portsc_buf[port_index] = 0;
+
+- if ((t1 & PORT_PE) && !(t1 & PORT_PLS_MASK)) {
+- xhci_dbg(xhci, "port %d not suspended\n", port_index);
+- slot_id = xhci_find_slot_id_by_port(hcd, xhci,
+- port_index + 1);
+- if (slot_id) {
++ /* Bail out if a USB3 port has a new device in link training */
++ if ((t1 & PORT_PLS_MASK) == XDEV_POLLING) {
++ bus_state->bus_suspended = 0;
++ spin_unlock_irqrestore(&xhci->lock, flags);
++ xhci_dbg(xhci, "Bus suspend bailout, port in polling\n");
++ return -EBUSY;
++ }
++
++ /* suspend ports in U0, or bail out for new connect changes */
++ if ((t1 & PORT_PE) && (t1 & PORT_PLS_MASK) == XDEV_U0) {
++ if ((t1 & PORT_CSC) && wake_enabled) {
++ bus_state->bus_suspended = 0;
+ spin_unlock_irqrestore(&xhci->lock, flags);
+- xhci_stop_device(xhci, slot_id, 1);
+- spin_lock_irqsave(&xhci->lock, flags);
++ xhci_dbg(xhci, "Bus suspend bailout, port connect change\n");
++ return -EBUSY;
+ }
++ xhci_dbg(xhci, "port %d not suspended\n", port_index);
+ t2 &= ~PORT_PLS_MASK;
+ t2 |= PORT_LINK_STROBE | XDEV_U3;
+ set_bit(port_index, &bus_state->bus_suspended);
+@@ -1518,7 +1531,7 @@ int xhci_bus_suspend(struct usb_hcd *hcd
+ * including the USB 3.0 roothub, but only if CONFIG_PM
+ * is enabled, so also enable remote wake here.
+ */
+- if (hcd->self.root_hub->do_remote_wakeup) {
++ if (wake_enabled) {
+ if (t1 & PORT_CONNECT) {
+ t2 |= PORT_WKOC_E | PORT_WKDISC_E;
+ t2 &= ~PORT_WKCONN_E;
+@@ -1538,7 +1551,26 @@ int xhci_bus_suspend(struct usb_hcd *hcd
+
+ t1 = xhci_port_state_to_neutral(t1);
+ if (t1 != t2)
+- writel(t2, ports[port_index]->addr);
++ portsc_buf[port_index] = t2;
++ }
++
++ /* write port settings, stopping and suspending ports if needed */
++ port_index = max_ports;
++ while (port_index--) {
++ if (!portsc_buf[port_index])
++ continue;
++ if (test_bit(port_index, &bus_state->bus_suspended)) {
++ int slot_id;
++
++ slot_id = xhci_find_slot_id_by_port(hcd, xhci,
++ port_index + 1);
++ if (slot_id) {
++ spin_unlock_irqrestore(&xhci->lock, flags);
++ xhci_stop_device(xhci, slot_id, 1);
++ spin_lock_irqsave(&xhci->lock, flags);
++ }
++ }
++ writel(portsc_buf[port_index], ports[port_index]->addr);
+ }
+ hcd->state = HC_STATE_SUSPENDED;
+ bus_state->next_statechange = jiffies + msecs_to_jiffies(10);
--- /dev/null
+From d9193efba84fe4c4aa22a569fade5e6ca971f8af Mon Sep 17 00:00:00 2001
+From: Sandeep Singh <sandeep.singh@amd.com>
+Date: Fri, 9 Nov 2018 17:21:19 +0200
+Subject: xhci: Add check for invalid byte size error when UAS devices are connected.
+
+From: Sandeep Singh <sandeep.singh@amd.com>
+
+commit d9193efba84fe4c4aa22a569fade5e6ca971f8af upstream.
+
+Observed "TRB completion code (27)" error which corresponds to Stopped -
+Length Invalid error(xhci spec section 4.17.4) while connecting USB to
+SATA bridge.
+
+Looks like this case was not considered when the following patch[1] was
+committed. Hence adding this new check which can prevent
+the invalid byte size error.
+
+[1] ade2e3a xhci: handle transfer events without TRB pointer
+
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Sandeep Singh <sandeep.singh@amd.com>
+cc: Nehal Shah <Nehal-bakulchandra.Shah@amd.com>
+cc: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
+Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/host/xhci-ring.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/usb/host/xhci-ring.c
++++ b/drivers/usb/host/xhci-ring.c
+@@ -2254,6 +2254,7 @@ static int handle_tx_event(struct xhci_h
+ goto cleanup;
+ case COMP_RING_UNDERRUN:
+ case COMP_RING_OVERRUN:
++ case COMP_STOPPED_LENGTH_INVALID:
+ goto cleanup;
+ default:
+ xhci_err(xhci, "ERROR Transfer event for unknown stream ring slot %u ep %u\n",
--- /dev/null
+From 11644a7659529730eaf2f166efaabe7c3dc7af8c Mon Sep 17 00:00:00 2001
+From: "Cherian, George" <George.Cherian@cavium.com>
+Date: Fri, 9 Nov 2018 17:21:22 +0200
+Subject: xhci: Add quirk to workaround the errata seen on Cavium Thunder-X2 Soc
+
+From: Cherian, George <George.Cherian@cavium.com>
+
+commit 11644a7659529730eaf2f166efaabe7c3dc7af8c upstream.
+
+Implement workaround for ThunderX2 Errata-129 (documented in
+CN99XX Known Issues" available at Cavium support site).
+As per ThunderX2errata-129, USB 2 device may come up as USB 1
+if a connection to a USB 1 device is followed by another connection to
+a USB 2 device, the link will come up as USB 1 for the USB 2 device.
+
+Resolution: Reset the PHY after the USB 1 device is disconnected.
+The PHY reset sequence is done using private registers in XHCI register
+space. After the PHY is reset we check for the PLL lock status and retry
+the operation if it fails. From our tests, retrying 4 times is sufficient.
+
+Add a new quirk flag XHCI_RESET_PLL_ON_DISCONNECT to invoke the workaround
+in handle_xhci_port_status().
+
+Cc: stable@vger.kernel.org
+Signed-off-by: George Cherian <george.cherian@cavium.com>
+Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/host/xhci-pci.c | 5 +++++
+ drivers/usb/host/xhci-ring.c | 35 ++++++++++++++++++++++++++++++++++-
+ drivers/usb/host/xhci.h | 1 +
+ 3 files changed, 40 insertions(+), 1 deletion(-)
+
+--- a/drivers/usb/host/xhci-pci.c
++++ b/drivers/usb/host/xhci-pci.c
+@@ -231,6 +231,11 @@ static void xhci_pci_quirks(struct devic
+ if (pdev->vendor == PCI_VENDOR_ID_TI && pdev->device == 0x8241)
+ xhci->quirks |= XHCI_LIMIT_ENDPOINT_INTERVAL_7;
+
++ if ((pdev->vendor == PCI_VENDOR_ID_BROADCOM ||
++ pdev->vendor == PCI_VENDOR_ID_CAVIUM) &&
++ pdev->device == 0x9026)
++ xhci->quirks |= XHCI_RESET_PLL_ON_DISCONNECT;
++
+ if (xhci->quirks & XHCI_RESET_ON_RESUME)
+ xhci_dbg_trace(xhci, trace_xhci_dbg_quirks,
+ "QUIRK: Resetting on resume");
+--- a/drivers/usb/host/xhci-ring.c
++++ b/drivers/usb/host/xhci-ring.c
+@@ -1517,6 +1517,35 @@ static void handle_device_notification(s
+ usb_wakeup_notification(udev->parent, udev->portnum);
+ }
+
++/*
++ * Quirk hanlder for errata seen on Cavium ThunderX2 processor XHCI
++ * Controller.
++ * As per ThunderX2errata-129 USB 2 device may come up as USB 1
++ * If a connection to a USB 1 device is followed by another connection
++ * to a USB 2 device.
++ *
++ * Reset the PHY after the USB device is disconnected if device speed
++ * is less than HCD_USB3.
++ * Retry the reset sequence max of 4 times checking the PLL lock status.
++ *
++ */
++static void xhci_cavium_reset_phy_quirk(struct xhci_hcd *xhci)
++{
++ struct usb_hcd *hcd = xhci_to_hcd(xhci);
++ u32 pll_lock_check;
++ u32 retry_count = 4;
++
++ do {
++ /* Assert PHY reset */
++ writel(0x6F, hcd->regs + 0x1048);
++ udelay(10);
++ /* De-assert the PHY reset */
++ writel(0x7F, hcd->regs + 0x1048);
++ udelay(200);
++ pll_lock_check = readl(hcd->regs + 0x1070);
++ } while (!(pll_lock_check & 0x1) && --retry_count);
++}
++
+ static void handle_port_status(struct xhci_hcd *xhci,
+ union xhci_trb *event)
+ {
+@@ -1650,8 +1679,12 @@ static void handle_port_status(struct xh
+ goto cleanup;
+ }
+
+- if (hcd->speed < HCD_USB3)
++ if (hcd->speed < HCD_USB3) {
+ xhci_test_and_clear_bit(xhci, port, PORT_PLC);
++ if ((xhci->quirks & XHCI_RESET_PLL_ON_DISCONNECT) &&
++ (portsc & PORT_CSC) && !(portsc & PORT_CONNECT))
++ xhci_cavium_reset_phy_quirk(xhci);
++ }
+
+ cleanup:
+ /* Update event ring dequeue pointer before dropping the lock */
+--- a/drivers/usb/host/xhci.h
++++ b/drivers/usb/host/xhci.h
+@@ -1846,6 +1846,7 @@ struct xhci_hcd {
+ #define XHCI_SUSPEND_DELAY BIT_ULL(30)
+ #define XHCI_INTEL_USB_ROLE_SW BIT_ULL(31)
+ #define XHCI_ZERO_64B_REGS BIT_ULL(32)
++#define XHCI_RESET_PLL_ON_DISCONNECT BIT_ULL(34)
+
+ unsigned int num_active_eps;
+ unsigned int limit_active_eps;
--- /dev/null
+From f068090426ea8d72c408ebd42953a82a88e2282c Mon Sep 17 00:00:00 2001
+From: Mathias Nyman <mathias.nyman@linux.intel.com>
+Date: Fri, 9 Nov 2018 17:21:17 +0200
+Subject: xhci: Fix leaking USB3 shared_hcd at xhci removal
+
+From: Mathias Nyman <mathias.nyman@linux.intel.com>
+
+commit f068090426ea8d72c408ebd42953a82a88e2282c upstream.
+
+Ensure that the shared_hcd pointer is valid when calling usb_put_hcd()
+
+The shared_hcd is removed and freed in xhci by first calling
+usb_remove_hcd(xhci->shared_hcd), and later
+usb_put_hcd(xhci->shared_hcd)
+
+Afer commit fe190ed0d602 ("xhci: Do not halt the host until both HCD have
+disconnected their devices.") the shared_hcd was never properly put as
+xhci->shared_hcd was set to NULL before usb_put_hcd(xhci->shared_hcd) was
+called.
+
+shared_hcd (USB3) is removed before primary hcd (USB2).
+While removing the primary hcd we might need to handle xhci interrupts
+to cleanly remove last USB2 devices, therefore we need to set
+xhci->shared_hcd to NULL before removing the primary hcd to let xhci
+interrupt handler know shared_hcd is no longer available.
+
+xhci-plat.c, xhci-histb.c and xhci-mtk first create both their hcd's before
+adding them. so to keep the correct reverse removal order use a temporary
+shared_hcd variable for them.
+For more details see commit 4ac53087d6d4 ("usb: xhci: plat: Create both
+HCDs before adding them")
+
+Fixes: fe190ed0d602 ("xhci: Do not halt the host until both HCD have disconnected their devices.")
+Cc: Joel Stanley <joel@jms.id.au>
+Cc: Chunfeng Yun <chunfeng.yun@mediatek.com>
+Cc: Thierry Reding <treding@nvidia.com>
+Cc: Jianguo Sun <sunjianguo1@huawei.com>
+Cc: <stable@vger.kernel.org>
+Reported-by: Jack Pham <jackp@codeaurora.org>
+Tested-by: Jack Pham <jackp@codeaurora.org>
+Tested-by: Peter Chen <peter.chen@nxp.com>
+Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/host/xhci-histb.c | 6 ++++--
+ drivers/usb/host/xhci-mtk.c | 6 ++++--
+ drivers/usb/host/xhci-pci.c | 1 +
+ drivers/usb/host/xhci-plat.c | 6 ++++--
+ drivers/usb/host/xhci-tegra.c | 1 +
+ drivers/usb/host/xhci.c | 2 --
+ 6 files changed, 14 insertions(+), 8 deletions(-)
+
+--- a/drivers/usb/host/xhci-histb.c
++++ b/drivers/usb/host/xhci-histb.c
+@@ -325,14 +325,16 @@ static int xhci_histb_remove(struct plat
+ struct xhci_hcd_histb *histb = platform_get_drvdata(dev);
+ struct usb_hcd *hcd = histb->hcd;
+ struct xhci_hcd *xhci = hcd_to_xhci(hcd);
++ struct usb_hcd *shared_hcd = xhci->shared_hcd;
+
+ xhci->xhc_state |= XHCI_STATE_REMOVING;
+
+- usb_remove_hcd(xhci->shared_hcd);
++ usb_remove_hcd(shared_hcd);
++ xhci->shared_hcd = NULL;
+ device_wakeup_disable(&dev->dev);
+
+ usb_remove_hcd(hcd);
+- usb_put_hcd(xhci->shared_hcd);
++ usb_put_hcd(shared_hcd);
+
+ xhci_histb_host_disable(histb);
+ usb_put_hcd(hcd);
+--- a/drivers/usb/host/xhci-mtk.c
++++ b/drivers/usb/host/xhci-mtk.c
+@@ -590,12 +590,14 @@ static int xhci_mtk_remove(struct platfo
+ struct xhci_hcd_mtk *mtk = platform_get_drvdata(dev);
+ struct usb_hcd *hcd = mtk->hcd;
+ struct xhci_hcd *xhci = hcd_to_xhci(hcd);
++ struct usb_hcd *shared_hcd = xhci->shared_hcd;
+
+- usb_remove_hcd(xhci->shared_hcd);
++ usb_remove_hcd(shared_hcd);
++ xhci->shared_hcd = NULL;
+ device_init_wakeup(&dev->dev, false);
+
+ usb_remove_hcd(hcd);
+- usb_put_hcd(xhci->shared_hcd);
++ usb_put_hcd(shared_hcd);
+ usb_put_hcd(hcd);
+ xhci_mtk_sch_exit(mtk);
+ xhci_mtk_clks_disable(mtk);
+--- a/drivers/usb/host/xhci-pci.c
++++ b/drivers/usb/host/xhci-pci.c
+@@ -356,6 +356,7 @@ static void xhci_pci_remove(struct pci_d
+ if (xhci->shared_hcd) {
+ usb_remove_hcd(xhci->shared_hcd);
+ usb_put_hcd(xhci->shared_hcd);
++ xhci->shared_hcd = NULL;
+ }
+
+ /* Workaround for spurious wakeups at shutdown with HSW */
+--- a/drivers/usb/host/xhci-plat.c
++++ b/drivers/usb/host/xhci-plat.c
+@@ -359,14 +359,16 @@ static int xhci_plat_remove(struct platf
+ struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+ struct clk *clk = xhci->clk;
+ struct clk *reg_clk = xhci->reg_clk;
++ struct usb_hcd *shared_hcd = xhci->shared_hcd;
+
+ xhci->xhc_state |= XHCI_STATE_REMOVING;
+
+- usb_remove_hcd(xhci->shared_hcd);
++ usb_remove_hcd(shared_hcd);
++ xhci->shared_hcd = NULL;
+ usb_phy_shutdown(hcd->usb_phy);
+
+ usb_remove_hcd(hcd);
+- usb_put_hcd(xhci->shared_hcd);
++ usb_put_hcd(shared_hcd);
+
+ clk_disable_unprepare(clk);
+ clk_disable_unprepare(reg_clk);
+--- a/drivers/usb/host/xhci-tegra.c
++++ b/drivers/usb/host/xhci-tegra.c
+@@ -1240,6 +1240,7 @@ static int tegra_xusb_remove(struct plat
+
+ usb_remove_hcd(xhci->shared_hcd);
+ usb_put_hcd(xhci->shared_hcd);
++ xhci->shared_hcd = NULL;
+ usb_remove_hcd(tegra->hcd);
+ usb_put_hcd(tegra->hcd);
+
+--- a/drivers/usb/host/xhci.c
++++ b/drivers/usb/host/xhci.c
+@@ -719,8 +719,6 @@ static void xhci_stop(struct usb_hcd *hc
+
+ /* Only halt host and free memory after both hcds are removed */
+ if (!usb_hcd_is_primary_hcd(hcd)) {
+- /* usb core will free this hcd shortly, unset pointer */
+- xhci->shared_hcd = NULL;
+ mutex_unlock(&xhci->mutex);
+ return;
+ }
--- /dev/null
+From 1245374e9b8340fc255fd51b2015173a83050d03 Mon Sep 17 00:00:00 2001
+From: Mathias Nyman <mathias.nyman@linux.intel.com>
+Date: Fri, 9 Nov 2018 17:21:18 +0200
+Subject: xhci: handle port status events for removed USB3 hcd
+
+From: Mathias Nyman <mathias.nyman@linux.intel.com>
+
+commit 1245374e9b8340fc255fd51b2015173a83050d03 upstream.
+
+At xhci removal the USB3 hcd (shared_hcd) is removed before the primary
+USB2 hcd. Interrupts for port status changes may still occur for USB3
+ports after the shared_hcd is freed, causing NULL pointer dereference.
+
+Check if xhci->shared_hcd is still valid before handing USB3 port events
+
+Cc: <stable@vger.kernel.org>
+Reported-by: Peter Chen <peter.chen@nxp.com>
+Tested-by: Jack Pham <jackp@codeaurora.org>
+Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/host/xhci-ring.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/drivers/usb/host/xhci-ring.c
++++ b/drivers/usb/host/xhci-ring.c
+@@ -1552,6 +1552,13 @@ static void handle_port_status(struct xh
+ goto cleanup;
+ }
+
++ /* We might get interrupts after shared_hcd is removed */
++ if (port->rhub == &xhci->usb3_rhub && xhci->shared_hcd == NULL) {
++ xhci_dbg(xhci, "ignore port event for removed USB3 hcd\n");
++ bogus_port_status = true;
++ goto cleanup;
++ }
++
+ hcd = port->rhub->hcd;
+ bus_state = &xhci->bus_state[hcd_index(hcd)];
+ hcd_portnum = port->hcd_portnum;
projects / thirdparty / kernel / stable-queue.git / commitdiff
