--- /dev/null
+From 28b2182dad43f6f8fcbd167539a26714fd12bd64 Mon Sep 17 00:00:00 2001
+From: Hans de Goede <hdegoede@redhat.com>
+Date: Fri, 2 Mar 2018 11:36:32 +0100
+Subject: ahci: Add PCI-id for the Highpoint Rocketraid 644L card
+
+From: Hans de Goede <hdegoede@redhat.com>
+
+commit 28b2182dad43f6f8fcbd167539a26714fd12bd64 upstream.
+
+Like the Highpoint Rocketraid 642L and cards using a Marvel 88SE9235
+controller in general, this RAID card also supports AHCI mode and short
+of a custom driver, this is the only way to make it work under Linux.
+
+Note that even though the card is called to 644L, it has a product-id
+of 0x0645.
+
+Cc: stable@vger.kernel.org
+BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1534106
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Tejun Heo <tj@kernel.org>
+Acked-by: Bjorn Helgaas <bhelgaas@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/ata/ahci.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/ata/ahci.c
++++ b/drivers/ata/ahci.c
+@@ -541,7 +541,9 @@ static const struct pci_device_id ahci_p
+ .driver_data = board_ahci_yes_fbs },
+ { PCI_DEVICE(PCI_VENDOR_ID_MARVELL_EXT, 0x9230),
+ .driver_data = board_ahci_yes_fbs },
+- { PCI_DEVICE(PCI_VENDOR_ID_TTI, 0x0642),
++ { PCI_DEVICE(PCI_VENDOR_ID_TTI, 0x0642), /* highpoint rocketraid 642L */
++ .driver_data = board_ahci_yes_fbs },
++ { PCI_DEVICE(PCI_VENDOR_ID_TTI, 0x0645), /* highpoint rocketraid 644L */
+ .driver_data = board_ahci_yes_fbs },
+
+ /* Promise */
--- /dev/null
+From 8e6b1a72a75bb5067ccb6b56d8ca4aa3a300a64e Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Thu, 22 Mar 2018 10:40:27 +0100
+Subject: ALSA: aloop: Fix access to not-yet-ready substream via cable
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit 8e6b1a72a75bb5067ccb6b56d8ca4aa3a300a64e upstream.
+
+In loopback_open() and loopback_close(), we assign and release the
+substream object to the corresponding cable in a racy way. It's
+neither locked nor done in the right position. The open callback
+assigns the substream before its preparation finishes, hence the other
+side of the cable may pick it up, which may lead to the invalid memory
+access.
+
+This patch addresses these: move the assignment to the end of the open
+callback, and wrap with cable->lock for avoiding concurrent accesses.
+
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/drivers/aloop.c | 8 +++++++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+--- a/sound/drivers/aloop.c
++++ b/sound/drivers/aloop.c
+@@ -666,7 +666,9 @@ static void free_cable(struct snd_pcm_su
+ return;
+ if (cable->streams[!substream->stream]) {
+ /* other stream is still alive */
++ spin_lock_irq(&cable->lock);
+ cable->streams[substream->stream] = NULL;
++ spin_unlock_irq(&cable->lock);
+ } else {
+ /* free the cable */
+ loopback->cables[substream->number][dev] = NULL;
+@@ -706,7 +708,6 @@ static int loopback_open(struct snd_pcm_
+ loopback->cables[substream->number][dev] = cable;
+ }
+ dpcm->cable = cable;
+- cable->streams[substream->stream] = dpcm;
+
+ snd_pcm_hw_constraint_integer(runtime, SNDRV_PCM_HW_PARAM_PERIODS);
+
+@@ -738,6 +739,11 @@ static int loopback_open(struct snd_pcm_
+ runtime->hw = loopback_pcm_hardware;
+ else
+ runtime->hw = cable->hw;
++
++ spin_lock_irq(&cable->lock);
++ cable->streams[substream->stream] = dpcm;
++ spin_unlock_irq(&cable->lock);
++
+ unlock:
+ if (err < 0) {
+ free_cable(substream);
--- /dev/null
+From 67a01afaf3d34893cf7d2ea19b34555d6abb7cb0 Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Thu, 22 Mar 2018 08:56:06 +0100
+Subject: ALSA: aloop: Sync stale timer before release
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit 67a01afaf3d34893cf7d2ea19b34555d6abb7cb0 upstream.
+
+The aloop driver tries to stop the pending timer via timer_del() in
+the trigger callback and in the close callback. The former is
+correct, as it's an atomic operation, while the latter expects that
+the timer gets really removed and proceeds the resource releases after
+that. But timer_del() doesn't synchronize, hence the running timer
+may still access the released resources.
+
+A similar situation can be also seen in the prepare callback after
+trigger(STOP) where the prepare tries to re-initialize the things
+while a timer is still running.
+
+The problems like the above are seen indirectly in some syzkaller
+reports (although it's not 100% clear whether this is the only cause,
+as the race condition is quite narrow and not always easy to
+trigger).
+
+For addressing these issues, this patch adds the explicit alls of
+timer_del_sync() in some places, so that the pending timer is properly
+killed / synced.
+
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/drivers/aloop.c | 9 ++++++++-
+ 1 file changed, 8 insertions(+), 1 deletion(-)
+
+--- a/sound/drivers/aloop.c
++++ b/sound/drivers/aloop.c
+@@ -192,6 +192,11 @@ static inline void loopback_timer_stop(s
+ dpcm->timer.expires = 0;
+ }
+
++static inline void loopback_timer_stop_sync(struct loopback_pcm *dpcm)
++{
++ del_timer_sync(&dpcm->timer);
++}
++
+ #define CABLE_VALID_PLAYBACK (1 << SNDRV_PCM_STREAM_PLAYBACK)
+ #define CABLE_VALID_CAPTURE (1 << SNDRV_PCM_STREAM_CAPTURE)
+ #define CABLE_VALID_BOTH (CABLE_VALID_PLAYBACK|CABLE_VALID_CAPTURE)
+@@ -326,6 +331,8 @@ static int loopback_prepare(struct snd_p
+ struct loopback_cable *cable = dpcm->cable;
+ int bps, salign;
+
++ loopback_timer_stop_sync(dpcm);
++
+ salign = (snd_pcm_format_width(runtime->format) *
+ runtime->channels) / 8;
+ bps = salign * runtime->rate;
+@@ -745,7 +752,7 @@ static int loopback_close(struct snd_pcm
+ struct loopback *loopback = substream->private_data;
+ struct loopback_pcm *dpcm = substream->runtime->private_data;
+
+- loopback_timer_stop(dpcm);
++ loopback_timer_stop_sync(dpcm);
+ mutex_lock(&loopback->cable_lock);
+ free_cable(substream);
+ mutex_unlock(&loopback->cable_lock);
--- /dev/null
+From a8d7bde23e7130686b76624b099f3e22dd38aef7 Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Wed, 21 Mar 2018 10:06:13 +0100
+Subject: ALSA: hda - Force polling mode on CFL for fixing codec communication
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit a8d7bde23e7130686b76624b099f3e22dd38aef7 upstream.
+
+We've observed too long probe time with Coffee Lake (CFL) machines,
+and the likely cause is some communication problem between the
+HD-audio controller and the codec chips. While the controller expects
+an IRQ wakeup for each codec response, it seems sometimes missing, and
+it takes one second for the controller driver to time out and read the
+response in the polling mode.
+
+Although we aren't sure about the real culprit yet, in this patch, we
+put a workaround by forcing the polling mode as default for CFL
+machines; the polling mode itself isn't too heavy, and much better
+than other workarounds initially suggested (e.g. disabling
+power-save), at least.
+
+Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199007
+Fixes: e79b0006c45c ("ALSA: hda - Add Coffelake PCI ID")
+Reported-and-tested-by: Hui Wang <hui.wang@canonical.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/pci/hda/hda_intel.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/sound/pci/hda/hda_intel.c
++++ b/sound/pci/hda/hda_intel.c
+@@ -375,6 +375,7 @@ enum {
+ ((pci)->device == 0x160c))
+
+ #define IS_BXT(pci) ((pci)->vendor == 0x8086 && (pci)->device == 0x5a98)
++#define IS_CFL(pci) ((pci)->vendor == 0x8086 && (pci)->device == 0xa348)
+
+ static char *driver_short_names[] = {
+ [AZX_DRIVER_ICH] = "HDA Intel",
+@@ -1744,6 +1745,10 @@ static int azx_create(struct snd_card *c
+ else
+ chip->bdl_pos_adj = bdl_pos_adj[dev];
+
++ /* Workaround for a communication error on CFL (bko#199007) */
++ if (IS_CFL(pci))
++ chip->polling_mode = 1;
++
+ err = azx_bus_init(chip, model[dev], &pci_hda_io_ops);
+ if (err < 0) {
+ kfree(hda);
--- /dev/null
+From e40bdb03d3cd7da66bd0bc1e40cbcfb49351265c Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Sat, 17 Mar 2018 22:40:18 +0100
+Subject: ALSA: hda/realtek - Always immediately update mute LED with pin VREF
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit e40bdb03d3cd7da66bd0bc1e40cbcfb49351265c upstream.
+
+Some HP laptops have a mute mute LED controlled by a pin VREF. The
+Realtek codec driver updates the VREF via vmaster hook by calling
+snd_hda_set_pin_ctl_cache().
+
+This works fine as long as the driver is running in a normal mode.
+However, when the VREF change happens during the codec being in
+runtime PM suspend, the regmap access will skip and postpone the
+actual register change. This ends up with the unchanged LED status
+until the next runtime PM resume even if you change the Master mute
+switch. (Interestingly, the machine keeps the LED status even after
+the codec goes into D3 -- but it's another story.)
+
+For improving this usability, let the driver temporarily powering up /
+down only during the pin VREF change. This can be achieved easily by
+wrapping the call with snd_hda_power_up_pm() / *_down_pm().
+
+Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199073
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/pci/hda/patch_realtek.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/sound/pci/hda/patch_realtek.c
++++ b/sound/pci/hda/patch_realtek.c
+@@ -3488,8 +3488,12 @@ static void alc269_fixup_mic_mute_hook(v
+ pinval = snd_hda_codec_get_pin_target(codec, spec->mute_led_nid);
+ pinval &= ~AC_PINCTL_VREFEN;
+ pinval |= enabled ? AC_PINCTL_VREF_HIZ : AC_PINCTL_VREF_80;
+- if (spec->mute_led_nid)
++ if (spec->mute_led_nid) {
++ /* temporarily power up/down for setting VREF */
++ snd_hda_power_up_pm(codec);
+ snd_hda_set_pin_ctl_cache(codec, spec->mute_led_nid, pinval);
++ snd_hda_power_down_pm(codec);
++ }
+ }
+
+ /* Make sure the led works even in runtime suspend */
--- /dev/null
+From f0ba9d699e5ca2bcd07f70185d18720c4f1b597c Mon Sep 17 00:00:00 2001
+From: Kailang Yang <kailang@realtek.com>
+Date: Fri, 16 Mar 2018 11:46:08 +0800
+Subject: ALSA: hda/realtek - Fix Dell headset Mic can't record
+
+From: Kailang Yang <kailang@realtek.com>
+
+commit f0ba9d699e5ca2bcd07f70185d18720c4f1b597c upstream.
+
+This platform was hardware fixed type for CTIA type for headset port.
+Assigned 0x19 verb will fix can't record issue.
+
+Signed-off-by: Kailang Yang <kailang@realtek.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/pci/hda/patch_realtek.c | 10 ++++++++++
+ 1 file changed, 10 insertions(+)
+
+--- a/sound/pci/hda/patch_realtek.c
++++ b/sound/pci/hda/patch_realtek.c
+@@ -5354,6 +5354,7 @@ enum {
+ ALC274_FIXUP_DELL_AIO_LINEOUT_VERB,
+ ALC298_FIXUP_TPT470_DOCK,
+ ALC255_FIXUP_DUMMY_LINEOUT_VERB,
++ ALC255_FIXUP_DELL_HEADSET_MIC,
+ };
+
+ static const struct hda_fixup alc269_fixups[] = {
+@@ -6214,6 +6215,13 @@ static const struct hda_fixup alc269_fix
+ .chained = true,
+ .chain_id = ALC255_FIXUP_DELL1_MIC_NO_PRESENCE
+ },
++ [ALC255_FIXUP_DELL_HEADSET_MIC] = {
++ .type = HDA_FIXUP_PINS,
++ .v.pins = (const struct hda_pintbl[]) {
++ { 0x19, 0x01a1913c }, /* use as headset mic, without its own jack detect */
++ { }
++ },
++ },
+ };
+
+ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
+@@ -6268,6 +6276,8 @@ static const struct snd_pci_quirk alc269
+ SND_PCI_QUIRK(0x1028, 0x082a, "Dell XPS 13 9360", ALC256_FIXUP_DELL_XPS_13_HEADPHONE_NOISE),
+ SND_PCI_QUIRK(0x1028, 0x084b, "Dell", ALC274_FIXUP_DELL_AIO_LINEOUT_VERB),
+ SND_PCI_QUIRK(0x1028, 0x084e, "Dell", ALC274_FIXUP_DELL_AIO_LINEOUT_VERB),
++ SND_PCI_QUIRK(0x1028, 0x0871, "Dell Precision 3630", ALC255_FIXUP_DELL_HEADSET_MIC),
++ SND_PCI_QUIRK(0x1028, 0x0872, "Dell Precision 3630", ALC255_FIXUP_DELL_HEADSET_MIC),
+ SND_PCI_QUIRK(0x1028, 0x0873, "Dell Precision 3930", ALC255_FIXUP_DUMMY_LINEOUT_VERB),
+ SND_PCI_QUIRK(0x1028, 0x164a, "Dell", ALC293_FIXUP_DELL1_MIC_NO_PRESENCE),
+ SND_PCI_QUIRK(0x1028, 0x164b, "Dell", ALC293_FIXUP_DELL1_MIC_NO_PRESENCE),
--- /dev/null
+From 88d42b2b45d7208cc872c2c9dec0b1ae6c6008d7 Mon Sep 17 00:00:00 2001
+From: Kailang Yang <kailang@realtek.com>
+Date: Wed, 14 Mar 2018 16:08:57 +0800
+Subject: ALSA: hda/realtek - Fix speaker no sound after system resume
+
+From: Kailang Yang <kailang@realtek.com>
+
+commit 88d42b2b45d7208cc872c2c9dec0b1ae6c6008d7 upstream.
+
+It will have a chance speaker no sound after system resume.
+To toggle NID 0x53 index 0x2 bit 15 will solve this issue.
+This usage will also suitable with ALC256.
+
+Fixes: 4a219ef8f370 ("ALSA: hda/realtek - Add ALC256 HP depop function")
+Signed-off-by: Kailang Yang <kailang@realtek.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/pci/hda/patch_realtek.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/sound/pci/hda/patch_realtek.c
++++ b/sound/pci/hda/patch_realtek.c
+@@ -3107,6 +3107,8 @@ static void alc256_init(struct hda_codec
+
+ alc_update_coef_idx(codec, 0x46, 3 << 12, 0);
+ alc_update_coefex_idx(codec, 0x57, 0x04, 0x0007, 0x4); /* Hight power */
++ alc_update_coefex_idx(codec, 0x53, 0x02, 0x8000, 1 << 15); /* Clear bit */
++ alc_update_coefex_idx(codec, 0x53, 0x02, 0x8000, 0 << 15);
+ }
+
+ static void alc256_shutup(struct hda_codec *codec)
+@@ -7004,6 +7006,8 @@ static int patch_alc269(struct hda_codec
+ break;
+ case 0x10ec0257:
+ spec->codec_variant = ALC269_TYPE_ALC257;
++ spec->shutup = alc256_shutup;
++ spec->init_hook = alc256_init;
+ spec->gen.mixer_nid = 0;
+ break;
+ case 0x10ec0215:
--- /dev/null
+From a6618f4aedb2b60932d766bd82ae7ce866e842aa Mon Sep 17 00:00:00 2001
+From: Kirill Marinushkin <k.marinushkin@gmail.com>
+Date: Mon, 19 Mar 2018 07:11:08 +0100
+Subject: ALSA: usb-audio: Fix parsing descriptor of UAC2 processing unit
+
+From: Kirill Marinushkin <k.marinushkin@gmail.com>
+
+commit a6618f4aedb2b60932d766bd82ae7ce866e842aa upstream.
+
+Currently, the offsets in the UAC2 processing unit descriptor are
+calculated incorrectly. It causes an issue when connecting the device which
+provides such a feature:
+
+~~~~
+[84126.724420] usb 1-1.3.1: invalid Processing Unit descriptor (id 18)
+~~~~
+
+After this patch is applied, the UAC2 processing unit inits w/o this error.
+
+Fixes: 23caaf19b11e ("ALSA: usb-mixer: Add support for Audio Class v2.0")
+Signed-off-by: Kirill Marinushkin <k.marinushkin@gmail.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ include/uapi/linux/usb/audio.h | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/include/uapi/linux/usb/audio.h
++++ b/include/uapi/linux/usb/audio.h
+@@ -370,7 +370,7 @@ static inline __u8 uac_processing_unit_b
+ {
+ return (protocol == UAC_VERSION_1) ?
+ desc->baSourceID[desc->bNrInPins + 4] :
+- desc->baSourceID[desc->bNrInPins + 6];
++ 2; /* in UAC2, this value is constant */
+ }
+
+ static inline __u8 *uac_processing_unit_bmControls(struct uac_processing_unit_descriptor *desc,
+@@ -378,7 +378,7 @@ static inline __u8 *uac_processing_unit_
+ {
+ return (protocol == UAC_VERSION_1) ?
+ &desc->baSourceID[desc->bNrInPins + 5] :
+- &desc->baSourceID[desc->bNrInPins + 7];
++ &desc->baSourceID[desc->bNrInPins + 6];
+ }
+
+ static inline __u8 uac_processing_unit_iProcessing(struct uac_processing_unit_descriptor *desc,
--- /dev/null
+From 49012d1bf5f78782d398adb984a080a88ba42965 Mon Sep 17 00:00:00 2001
+From: Boris Brezillon <boris.brezillon@bootlin.com>
+Date: Thu, 8 Feb 2018 14:43:35 +0100
+Subject: clk: bcm2835: Fix ana->maskX definitions
+
+From: Boris Brezillon <boris.brezillon@bootlin.com>
+
+commit 49012d1bf5f78782d398adb984a080a88ba42965 upstream.
+
+ana->maskX values are already '~'-ed in bcm2835_pll_set_rate(). Remove
+the '~' in the definition to fix ANA setup.
+
+Note that this commit fixes a long standing bug preventing one from
+using an HDMI display if it's plugged after the FW has booted Linux.
+This is because PLLH is used by the HDMI encoder to generate the pixel
+clock.
+
+Fixes: 41691b8862e2 ("clk: bcm2835: Add support for programming the audio domain clocks")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
+Reviewed-by: Eric Anholt <eric@anholt.net>
+Signed-off-by: Stephen Boyd <sboyd@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/clk/bcm/clk-bcm2835.c | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+--- a/drivers/clk/bcm/clk-bcm2835.c
++++ b/drivers/clk/bcm/clk-bcm2835.c
+@@ -479,17 +479,17 @@ struct bcm2835_pll_ana_bits {
+ static const struct bcm2835_pll_ana_bits bcm2835_ana_default = {
+ .mask0 = 0,
+ .set0 = 0,
+- .mask1 = (u32)~(A2W_PLL_KI_MASK | A2W_PLL_KP_MASK),
++ .mask1 = A2W_PLL_KI_MASK | A2W_PLL_KP_MASK,
+ .set1 = (2 << A2W_PLL_KI_SHIFT) | (8 << A2W_PLL_KP_SHIFT),
+- .mask3 = (u32)~A2W_PLL_KA_MASK,
++ .mask3 = A2W_PLL_KA_MASK,
+ .set3 = (2 << A2W_PLL_KA_SHIFT),
+ .fb_prediv_mask = BIT(14),
+ };
+
+ static const struct bcm2835_pll_ana_bits bcm2835_ana_pllh = {
+- .mask0 = (u32)~(A2W_PLLH_KA_MASK | A2W_PLLH_KI_LOW_MASK),
++ .mask0 = A2W_PLLH_KA_MASK | A2W_PLLH_KI_LOW_MASK,
+ .set0 = (2 << A2W_PLLH_KA_SHIFT) | (2 << A2W_PLLH_KI_LOW_SHIFT),
+- .mask1 = (u32)~(A2W_PLLH_KI_HIGH_MASK | A2W_PLLH_KP_MASK),
++ .mask1 = A2W_PLLH_KI_HIGH_MASK | A2W_PLLH_KP_MASK,
+ .set1 = (6 << A2W_PLLH_KP_SHIFT),
+ .mask3 = 0,
+ .set3 = 0,
--- /dev/null
+From 7997f3b2df751aab0b8e60149b226a32966c41ac Mon Sep 17 00:00:00 2001
+From: Boris Brezillon <boris.brezillon@bootlin.com>
+Date: Thu, 8 Feb 2018 14:43:36 +0100
+Subject: clk: bcm2835: Protect sections updating shared registers
+
+From: Boris Brezillon <boris.brezillon@bootlin.com>
+
+commit 7997f3b2df751aab0b8e60149b226a32966c41ac upstream.
+
+CM_PLLx and A2W_XOSC_CTRL registers are accessed by different clock
+handlers and must be accessed with ->regs_lock held.
+Update the sections where this protection is missing.
+
+Fixes: 41691b8862e2 ("clk: bcm2835: Add support for programming the audio domain clocks")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
+Reviewed-by: Eric Anholt <eric@anholt.net>
+Signed-off-by: Stephen Boyd <sboyd@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/clk/bcm/clk-bcm2835.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/drivers/clk/bcm/clk-bcm2835.c
++++ b/drivers/clk/bcm/clk-bcm2835.c
+@@ -653,8 +653,10 @@ static int bcm2835_pll_on(struct clk_hw
+ ~A2W_PLL_CTRL_PWRDN);
+
+ /* Take the PLL out of reset. */
++ spin_lock(&cprman->regs_lock);
+ cprman_write(cprman, data->cm_ctrl_reg,
+ cprman_read(cprman, data->cm_ctrl_reg) & ~CM_PLL_ANARST);
++ spin_unlock(&cprman->regs_lock);
+
+ /* Wait for the PLL to lock. */
+ timeout = ktime_add_ns(ktime_get(), LOCK_TIMEOUT_NS);
+@@ -731,9 +733,11 @@ static int bcm2835_pll_set_rate(struct c
+ }
+
+ /* Unmask the reference clock from the oscillator. */
++ spin_lock(&cprman->regs_lock);
+ cprman_write(cprman, A2W_XOSC_CTRL,
+ cprman_read(cprman, A2W_XOSC_CTRL) |
+ data->reference_enable_mask);
++ spin_unlock(&cprman->regs_lock);
+
+ if (do_ana_setup_first)
+ bcm2835_pll_write_ana(cprman, data->ana_reg_base, ana);
--- /dev/null
+From 5682e268350f9eccdbb04006605c1b7068a7b323 Mon Sep 17 00:00:00 2001
+From: Chen-Yu Tsai <wens@csie.org>
+Date: Sat, 17 Feb 2018 21:05:04 +0800
+Subject: clk: sunxi-ng: a31: Fix CLK_OUT_* clock ops
+
+From: Chen-Yu Tsai <wens@csie.org>
+
+commit 5682e268350f9eccdbb04006605c1b7068a7b323 upstream.
+
+When support for the A31/A31s CCU was first added, the clock ops for
+the CLK_OUT_* clocks was set to the wrong type. The clocks are MP-type,
+but the ops was set for div (M) clocks. This went unnoticed until now.
+This was because while they are different clocks, their data structures
+aligned in a way that ccu_div_ops would access the second ccu_div_internal
+and ccu_mux_internal structures, which were valid, if not incorrect.
+
+Furthermore, the use of these CLK_OUT_* was for feeding a precise 32.768
+kHz clock signal to the WiFi chip. This was achievable by using the parent
+with the same clock rate and no divider. So the incorrect divider setting
+did not affect this usage.
+
+Commit 946797aa3f08 ("clk: sunxi-ng: Support fixed post-dividers on MP
+style clocks") added a new field to the ccu_mp structure, which broke
+the aforementioned alignment. Now the system crashes as div_ops tries
+to look up a nonexistent table.
+
+Reported-by: Philipp Rossak <embed3d@gmail.com>
+Tested-by: Philipp Rossak <embed3d@gmail.com>
+Fixes: c6e6c96d8fa6 ("clk: sunxi-ng: Add A31/A31s clocks")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Chen-Yu Tsai <wens@csie.org>
+Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/clk/sunxi-ng/ccu-sun6i-a31.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
++++ b/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
+@@ -750,7 +750,7 @@ static struct ccu_mp out_a_clk = {
+ .features = CCU_FEATURE_FIXED_PREDIV,
+ .hw.init = CLK_HW_INIT_PARENTS("out-a",
+ clk_out_parents,
+- &ccu_div_ops,
++ &ccu_mp_ops,
+ 0),
+ },
+ };
+@@ -771,7 +771,7 @@ static struct ccu_mp out_b_clk = {
+ .features = CCU_FEATURE_FIXED_PREDIV,
+ .hw.init = CLK_HW_INIT_PARENTS("out-b",
+ clk_out_parents,
+- &ccu_div_ops,
++ &ccu_mp_ops,
+ 0),
+ },
+ };
+@@ -792,7 +792,7 @@ static struct ccu_mp out_c_clk = {
+ .features = CCU_FEATURE_FIXED_PREDIV,
+ .hw.init = CLK_HW_INIT_PARENTS("out-c",
+ clk_out_parents,
+- &ccu_div_ops,
++ &ccu_mp_ops,
+ 0),
+ },
+ };
--- /dev/null
+From 655296c8bbeffcf020558c4455305d597a73bde1 Mon Sep 17 00:00:00 2001
+From: Michael Kelley <mhkelley@outlook.com>
+Date: Sun, 4 Mar 2018 22:24:08 -0700
+Subject: Drivers: hv: vmbus: Fix ring buffer signaling
+
+From: Michael Kelley <mhkelley@outlook.com>
+
+commit 655296c8bbeffcf020558c4455305d597a73bde1 upstream.
+
+Fix bugs in signaling the Hyper-V host when freeing space in the
+host->guest ring buffer:
+
+1. The interrupt_mask must not be used to determine whether to signal
+ on the host->guest ring buffer
+2. The ring buffer write_index must be read (via hv_get_bytes_to_write)
+ *after* pending_send_sz is read in order to avoid a race condition
+3. Comparisons with pending_send_sz must treat the "equals" case as
+ not-enough-space
+4. Don't signal if the pending_send_sz feature is not present. Older
+ versions of Hyper-V that don't implement this feature will poll.
+
+Fixes: 03bad714a161 ("vmbus: more host signalling avoidance")
+
+Cc: Stable <stable@vger.kernel.org> # 4.14 and above
+Signed-off-by: Michael Kelley <mhkelley@outlook.com>
+Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/hv/ring_buffer.c | 54 +++++++++++++++++++++++++++++++----------------
+ 1 file changed, 36 insertions(+), 18 deletions(-)
+
+--- a/drivers/hv/ring_buffer.c
++++ b/drivers/hv/ring_buffer.c
+@@ -394,13 +394,24 @@ __hv_pkt_iter_next(struct vmbus_channel
+ }
+ EXPORT_SYMBOL_GPL(__hv_pkt_iter_next);
+
++/* How many bytes were read in this iterator cycle */
++static u32 hv_pkt_iter_bytes_read(const struct hv_ring_buffer_info *rbi,
++ u32 start_read_index)
++{
++ if (rbi->priv_read_index >= start_read_index)
++ return rbi->priv_read_index - start_read_index;
++ else
++ return rbi->ring_datasize - start_read_index +
++ rbi->priv_read_index;
++}
++
+ /*
+ * Update host ring buffer after iterating over packets.
+ */
+ void hv_pkt_iter_close(struct vmbus_channel *channel)
+ {
+ struct hv_ring_buffer_info *rbi = &channel->inbound;
+- u32 orig_write_sz = hv_get_bytes_to_write(rbi);
++ u32 curr_write_sz, pending_sz, bytes_read, start_read_index;
+
+ /*
+ * Make sure all reads are done before we update the read index since
+@@ -408,8 +419,12 @@ void hv_pkt_iter_close(struct vmbus_chan
+ * is updated.
+ */
+ virt_rmb();
++ start_read_index = rbi->ring_buffer->read_index;
+ rbi->ring_buffer->read_index = rbi->priv_read_index;
+
++ if (!rbi->ring_buffer->feature_bits.feat_pending_send_sz)
++ return;
++
+ /*
+ * Issue a full memory barrier before making the signaling decision.
+ * Here is the reason for having this barrier:
+@@ -423,26 +438,29 @@ void hv_pkt_iter_close(struct vmbus_chan
+ */
+ virt_mb();
+
+- /* If host has disabled notifications then skip */
+- if (rbi->ring_buffer->interrupt_mask)
++ pending_sz = READ_ONCE(rbi->ring_buffer->pending_send_sz);
++ if (!pending_sz)
+ return;
+
+- if (rbi->ring_buffer->feature_bits.feat_pending_send_sz) {
+- u32 pending_sz = READ_ONCE(rbi->ring_buffer->pending_send_sz);
++ /*
++ * Ensure the read of write_index in hv_get_bytes_to_write()
++ * happens after the read of pending_send_sz.
++ */
++ virt_rmb();
++ curr_write_sz = hv_get_bytes_to_write(rbi);
++ bytes_read = hv_pkt_iter_bytes_read(rbi, start_read_index);
++
++ /*
++ * If there was space before we began iteration,
++ * then host was not blocked.
++ */
+
+- /*
+- * If there was space before we began iteration,
+- * then host was not blocked. Also handles case where
+- * pending_sz is zero then host has nothing pending
+- * and does not need to be signaled.
+- */
+- if (orig_write_sz > pending_sz)
+- return;
+-
+- /* If pending write will not fit, don't give false hope. */
+- if (hv_get_bytes_to_write(rbi) < pending_sz)
+- return;
+- }
++ if (curr_write_sz - bytes_read > pending_sz)
++ return;
++
++ /* If pending write will not fit, don't give false hope. */
++ if (curr_write_sz <= pending_sz)
++ return;
+
+ vmbus_setevent(channel);
+ }
--- /dev/null
+From 3c3e4b3a708a9d6451052e348981f37d2b3e92b0 Mon Sep 17 00:00:00 2001
+From: Dan Carpenter <dan.carpenter@oracle.com>
+Date: Thu, 8 Mar 2018 12:31:53 +0300
+Subject: iio: adc: meson-saradc: unlock on error in meson_sar_adc_lock()
+
+From: Dan Carpenter <dan.carpenter@oracle.com>
+
+commit 3c3e4b3a708a9d6451052e348981f37d2b3e92b0 upstream.
+
+The meson_sar_adc_lock() function is not supposed to hold the
+"indio_dev->mlock" on the error path.
+
+Fixes: 3adbf3427330 ("iio: adc: add a driver for the SAR ADC found in Amlogic Meson SoCs")
+Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/iio/adc/meson_saradc.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/iio/adc/meson_saradc.c
++++ b/drivers/iio/adc/meson_saradc.c
+@@ -462,8 +462,10 @@ static int meson_sar_adc_lock(struct iio
+ regmap_read(priv->regmap, MESON_SAR_ADC_DELAY, &val);
+ } while (val & MESON_SAR_ADC_DELAY_BL30_BUSY && timeout--);
+
+- if (timeout < 0)
++ if (timeout < 0) {
++ mutex_unlock(&indio_dev->mlock);
+ return -ETIMEDOUT;
++ }
+ }
+
+ return 0;
--- /dev/null
+From b91e146c38b003c899710ede6d05fc824675e386 Mon Sep 17 00:00:00 2001
+From: Richard Lai <richard@richardman.com>
+Date: Sat, 17 Feb 2018 16:28:24 +0000
+Subject: iio: chemical: ccs811: Corrected firmware boot/application mode transition
+
+From: Richard Lai <richard@richardman.com>
+
+commit b91e146c38b003c899710ede6d05fc824675e386 upstream.
+
+CCS811 has different I2C register maps in boot and application mode. When
+CCS811 is in boot mode, register APP_START (0xF4) is used to transit the
+firmware state from boot to application mode. However, APP_START is not a
+valid register location when CCS811 is in application mode (refer to
+"CCS811 Bootloader Register Map" and "CCS811 Application Register Map" in
+CCS811 datasheet). The driver should not attempt to perform a write to
+APP_START while CCS811 is in application mode, as this is not a valid or
+documented register location.
+
+When prob function is being called, the driver assumes the CCS811 sensor
+is in boot mode, and attempts to perform a write to APP_START. Although
+CCS811 powers-up in boot mode, it may have already been transited to
+application mode by previous instances, e.g. unload and reload device
+driver by the system, or explicitly by user. Depending on the system
+design, CCS811 sensor may be permanently connected to system power source
+rather than power controlled by GPIO, hence it is possible that the sensor
+is never power reset, thus the firmware could be in either boot or
+application mode at any given time when driver prob function is being
+called.
+
+This patch checks the STATUS register before attempting to send a write to
+APP_START. Only if the firmware is not in application mode and has valid
+firmware application loaded, then it will continue to start transiting the
+firmware boot to application mode.
+
+Signed-off-by: Richard Lai <richard@richardman.com>
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/iio/chemical/ccs811.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/iio/chemical/ccs811.c
++++ b/drivers/iio/chemical/ccs811.c
+@@ -128,6 +128,9 @@ static int ccs811_start_sensor_applicati
+ if (ret < 0)
+ return ret;
+
++ if ((ret & CCS811_STATUS_FW_MODE_APPLICATION))
++ return 0;
++
+ if ((ret & CCS811_STATUS_APP_VALID_MASK) !=
+ CCS811_STATUS_APP_VALID_LOADED)
+ return -EIO;
--- /dev/null
+From 8b438686a001db64c21782d04ef68111e53c45d9 Mon Sep 17 00:00:00 2001
+From: Michael Nosthoff <committed@heine.so>
+Date: Fri, 9 Mar 2018 10:02:45 +0100
+Subject: iio: st_pressure: st_accel: pass correct platform data to init
+
+From: Michael Nosthoff <committed@heine.so>
+
+commit 8b438686a001db64c21782d04ef68111e53c45d9 upstream.
+
+Commit 7383d44b added a pointer pdata which get set to the default
+platform_data when non was defined in the device. But it did not
+pass this pointer to the st_sensors_init_sensor call but still
+used the maybe uninitialized platform_data from dev.
+
+This breaks initialization when no platform_data is given and
+the optional st,drdy-int-pin devicetree option is not set.
+
+This commit fixes this.
+
+Cc: stable@vger.kernel.org
+Fixes: 7383d44b ("iio: st_pressure: st_accel: Initialise sensor platform data properly")
+Signed-off-by: Michael Nosthoff <committed@heine.so>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/iio/accel/st_accel_core.c | 2 +-
+ drivers/iio/pressure/st_pressure_core.c | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/iio/accel/st_accel_core.c
++++ b/drivers/iio/accel/st_accel_core.c
+@@ -794,7 +794,7 @@ int st_accel_common_probe(struct iio_dev
+ if (!pdata)
+ pdata = (struct st_sensors_platform_data *)&default_accel_pdata;
+
+- err = st_sensors_init_sensor(indio_dev, adata->dev->platform_data);
++ err = st_sensors_init_sensor(indio_dev, pdata);
+ if (err < 0)
+ goto st_accel_power_off;
+
+--- a/drivers/iio/pressure/st_pressure_core.c
++++ b/drivers/iio/pressure/st_pressure_core.c
+@@ -617,7 +617,7 @@ int st_press_common_probe(struct iio_dev
+ if (!pdata && press_data->sensor_settings->drdy_irq.addr)
+ pdata = (struct st_sensors_platform_data *)&default_press_pdata;
+
+- err = st_sensors_init_sensor(indio_dev, press_data->dev->platform_data);
++ err = st_sensors_init_sensor(indio_dev, pdata);
+ if (err < 0)
+ goto st_press_power_off;
+
--- /dev/null
+From 2e517d681632326ed98399cb4dd99519efe3e32c Mon Sep 17 00:00:00 2001
+From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
+Date: Thu, 22 Mar 2018 16:17:10 -0700
+Subject: lockdep: fix fs_reclaim warning
+
+From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
+
+commit 2e517d681632326ed98399cb4dd99519efe3e32c upstream.
+
+Dave Jones reported fs_reclaim lockdep warnings.
+
+ ============================================
+ WARNING: possible recursive locking detected
+ 4.15.0-rc9-backup-debug+ #1 Not tainted
+ --------------------------------------------
+ sshd/24800 is trying to acquire lock:
+ (fs_reclaim){+.+.}, at: [<0000000084f438c2>] fs_reclaim_acquire.part.102+0x5/0x30
+
+ but task is already holding lock:
+ (fs_reclaim){+.+.}, at: [<0000000084f438c2>] fs_reclaim_acquire.part.102+0x5/0x30
+
+ other info that might help us debug this:
+ Possible unsafe locking scenario:
+
+ CPU0
+ ----
+ lock(fs_reclaim);
+ lock(fs_reclaim);
+
+ *** DEADLOCK ***
+
+ May be due to missing lock nesting notation
+
+ 2 locks held by sshd/24800:
+ #0: (sk_lock-AF_INET6){+.+.}, at: [<000000001a069652>] tcp_sendmsg+0x19/0x40
+ #1: (fs_reclaim){+.+.}, at: [<0000000084f438c2>] fs_reclaim_acquire.part.102+0x5/0x30
+
+ stack backtrace:
+ CPU: 3 PID: 24800 Comm: sshd Not tainted 4.15.0-rc9-backup-debug+ #1
+ Call Trace:
+ dump_stack+0xbc/0x13f
+ __lock_acquire+0xa09/0x2040
+ lock_acquire+0x12e/0x350
+ fs_reclaim_acquire.part.102+0x29/0x30
+ kmem_cache_alloc+0x3d/0x2c0
+ alloc_extent_state+0xa7/0x410
+ __clear_extent_bit+0x3ea/0x570
+ try_release_extent_mapping+0x21a/0x260
+ __btrfs_releasepage+0xb0/0x1c0
+ btrfs_releasepage+0x161/0x170
+ try_to_release_page+0x162/0x1c0
+ shrink_page_list+0x1d5a/0x2fb0
+ shrink_inactive_list+0x451/0x940
+ shrink_node_memcg.constprop.88+0x4c9/0x5e0
+ shrink_node+0x12d/0x260
+ try_to_free_pages+0x418/0xaf0
+ __alloc_pages_slowpath+0x976/0x1790
+ __alloc_pages_nodemask+0x52c/0x5c0
+ new_slab+0x374/0x3f0
+ ___slab_alloc.constprop.81+0x47e/0x5a0
+ __slab_alloc.constprop.80+0x32/0x60
+ __kmalloc_track_caller+0x267/0x310
+ __kmalloc_reserve.isra.40+0x29/0x80
+ __alloc_skb+0xee/0x390
+ sk_stream_alloc_skb+0xb8/0x340
+ tcp_sendmsg_locked+0x8e6/0x1d30
+ tcp_sendmsg+0x27/0x40
+ inet_sendmsg+0xd0/0x310
+ sock_write_iter+0x17a/0x240
+ __vfs_write+0x2ab/0x380
+ vfs_write+0xfb/0x260
+ SyS_write+0xb6/0x140
+ do_syscall_64+0x1e5/0xc05
+ entry_SYSCALL64_slow_path+0x25/0x25
+
+This warning is caused by commit d92a8cfcb37e ("locking/lockdep:
+Rework FS_RECLAIM annotation") which replaced the use of
+lockdep_{set,clear}_current_reclaim_state() in __perform_reclaim()
+and lockdep_trace_alloc() in slab_pre_alloc_hook() with
+fs_reclaim_acquire()/ fs_reclaim_release().
+
+Since __kmalloc_reserve() from __alloc_skb() adds __GFP_NOMEMALLOC |
+__GFP_NOWARN to gfp_mask, and all reclaim path simply propagates
+__GFP_NOMEMALLOC, fs_reclaim_acquire() in slab_pre_alloc_hook() is
+trying to grab the 'fake' lock again when __perform_reclaim() already
+grabbed the 'fake' lock.
+
+The
+
+ /* this guy won't enter reclaim */
+ if ((current->flags & PF_MEMALLOC) && !(gfp_mask & __GFP_NOMEMALLOC))
+ return false;
+
+test which causes slab_pre_alloc_hook() to try to grab the 'fake' lock
+was added by commit cf40bd16fdad ("lockdep: annotate reclaim context
+(__GFP_NOFS)"). But that test is outdated because PF_MEMALLOC thread
+won't enter reclaim regardless of __GFP_NOMEMALLOC after commit
+341ce06f69ab ("page allocator: calculate the alloc_flags for allocation
+only once") added the PF_MEMALLOC safeguard (
+
+ /* Avoid recursion of direct reclaim */
+ if (p->flags & PF_MEMALLOC)
+ goto nopage;
+
+in __alloc_pages_slowpath()).
+
+Thus, let's fix outdated test by removing __GFP_NOMEMALLOC test and
+allow __need_fs_reclaim() to return false.
+
+Link: http://lkml.kernel.org/r/201802280650.FJC73911.FOSOMLJVFFQtHO@I-love.SAKURA.ne.jp
+Fixes: d92a8cfcb37ecd13 ("locking/lockdep: Rework FS_RECLAIM annotation")
+Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
+Reported-by: Dave Jones <davej@codemonkey.org.uk>
+Tested-by: Dave Jones <davej@codemonkey.org.uk>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Nick Piggin <npiggin@gmail.com>
+Cc: Ingo Molnar <mingo@elte.hu>
+Cc: Nikolay Borisov <nborisov@suse.com>
+Cc: Michal Hocko <mhocko@kernel.org>
+Cc: <stable@vger.kernel.org> [4.14+]
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ mm/page_alloc.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/mm/page_alloc.c
++++ b/mm/page_alloc.c
+@@ -3532,7 +3532,7 @@ static bool __need_fs_reclaim(gfp_t gfp_
+ return false;
+
+ /* this guy won't enter reclaim */
+- if ((current->flags & PF_MEMALLOC) && !(gfp_mask & __GFP_NOMEMALLOC))
++ if (current->flags & PF_MEMALLOC)
+ return false;
+
+ /* We're only interested __GFP_FS allocations for now */
--- /dev/null
+From a821328c2f3003b908880792d71b2781b44fa53c Mon Sep 17 00:00:00 2001
+From: Mathias Kresin <dev@kresin.me>
+Date: Fri, 16 Mar 2018 21:27:30 +0100
+Subject: MIPS: lantiq: ase: Enable MFD_SYSCON
+
+From: Mathias Kresin <dev@kresin.me>
+
+commit a821328c2f3003b908880792d71b2781b44fa53c upstream.
+
+Enable syscon to use it for the RCU MFD on Amazon SE as well.
+
+The Amazon SE also has similar reset controller system as Danube and
+XWAY and use their drivers mostly. As these drivers now need syscon also
+activate the syscon subsystem for for Amazon SE.
+
+Fixes: 2b6639d4c794 ("MIPS: lantiq: Enable MFD_SYSCON to be able to use it for the RCU MFD")
+Signed-off-by: Mathias Kresin <dev@kresin.me>
+Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
+Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+Cc: Ralf Baechle <ralf@linux-mips.org>
+Cc: John Crispin <john@phrozen.org>
+Cc: linux-mips@linux-mips.org
+Cc: <stable@vger.kernel.org> # 4.14+
+Patchwork: https://patchwork.linux-mips.org/patch/18817/
+Signed-off-by: James Hogan <jhogan@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/mips/lantiq/Kconfig | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/arch/mips/lantiq/Kconfig
++++ b/arch/mips/lantiq/Kconfig
+@@ -13,6 +13,8 @@ choice
+ config SOC_AMAZON_SE
+ bool "Amazon SE"
+ select SOC_TYPE_XWAY
++ select MFD_SYSCON
++ select MFD_CORE
+
+ config SOC_XWAY
+ bool "XWAY"
--- /dev/null
+From 3223a5a7d3a606dcb7d9190a788b9544a45441ee Mon Sep 17 00:00:00 2001
+From: Mathias Kresin <dev@kresin.me>
+Date: Fri, 16 Mar 2018 21:27:29 +0100
+Subject: MIPS: lantiq: Enable AHB Bus for USB
+
+From: Mathias Kresin <dev@kresin.me>
+
+commit 3223a5a7d3a606dcb7d9190a788b9544a45441ee upstream.
+
+On Danube and AR9 the USB core is connected though a AHB bus to the main
+system cross bar, hence we need to enable the gating clock of the AHB
+Bus as well to make the USB controller work.
+
+Fixes: dea54fbad332 ("phy: Add an USB PHY driver for the Lantiq SoCs using the RCU module")
+Signed-off-by: Mathias Kresin <dev@kresin.me>
+Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
+Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+Cc: Ralf Baechle <ralf@linux-mips.org>
+Cc: John Crispin <john@phrozen.org>
+Cc: linux-mips@linux-mips.org
+Cc: <stable@vger.kernel.org> # 4.14+
+Patchwork: https://patchwork.linux-mips.org/patch/18814/
+Signed-off-by: James Hogan <jhogan@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/mips/lantiq/xway/sysctrl.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/arch/mips/lantiq/xway/sysctrl.c
++++ b/arch/mips/lantiq/xway/sysctrl.c
+@@ -551,9 +551,9 @@ void __init ltq_soc_init(void)
+ clkdev_add_static(ltq_ar9_cpu_hz(), ltq_ar9_fpi_hz(),
+ ltq_ar9_fpi_hz(), CLOCK_250M);
+ clkdev_add_pmu("1f203018.usb2-phy", "phy", 1, 0, PMU_USB0_P);
+- clkdev_add_pmu("1e101000.usb", "otg", 1, 0, PMU_USB0);
++ clkdev_add_pmu("1e101000.usb", "otg", 1, 0, PMU_USB0 | PMU_AHBM);
+ clkdev_add_pmu("1f203034.usb2-phy", "phy", 1, 0, PMU_USB1_P);
+- clkdev_add_pmu("1e106000.usb", "otg", 1, 0, PMU_USB1);
++ clkdev_add_pmu("1e106000.usb", "otg", 1, 0, PMU_USB1 | PMU_AHBM);
+ clkdev_add_pmu("1e180000.etop", "switch", 1, 0, PMU_SWITCH);
+ clkdev_add_pmu("1e103000.sdio", NULL, 1, 0, PMU_SDIO);
+ clkdev_add_pmu("1e103100.deu", NULL, 1, 0, PMU_DEU);
+@@ -562,7 +562,7 @@ void __init ltq_soc_init(void)
+ } else {
+ clkdev_add_static(ltq_danube_cpu_hz(), ltq_danube_fpi_hz(),
+ ltq_danube_fpi_hz(), ltq_danube_pp32_hz());
+- clkdev_add_pmu("1e101000.usb", "otg", 1, 0, PMU_USB0);
++ clkdev_add_pmu("1e101000.usb", "otg", 1, 0, PMU_USB0 | PMU_AHBM);
+ clkdev_add_pmu("1f203018.usb2-phy", "phy", 1, 0, PMU_USB0_P);
+ clkdev_add_pmu("1e103000.sdio", NULL, 1, 0, PMU_SDIO);
+ clkdev_add_pmu("1e103100.deu", NULL, 1, 0, PMU_DEU);
--- /dev/null
+From 214cbc14734958fe533916fdb4194f5983ad4bc4 Mon Sep 17 00:00:00 2001
+From: Mathias Kresin <dev@kresin.me>
+Date: Fri, 16 Mar 2018 21:27:28 +0100
+Subject: MIPS: lantiq: Fix Danube USB clock
+
+From: Mathias Kresin <dev@kresin.me>
+
+commit 214cbc14734958fe533916fdb4194f5983ad4bc4 upstream.
+
+On Danube the USB0 controller registers are at 1e101000 and the USB0 PHY
+register is at 1f203018 similar to all other lantiq SoCs. Activate the
+USB controller gating clock thorough the USB controller driver and not
+the PHY.
+
+This fixes a problem introduced in a previous commit.
+
+Fixes: dea54fbad332 ("phy: Add an USB PHY driver for the Lantiq SoCs using the RCU module")
+Signed-off-by: Mathias Kresin <dev@kresin.me>
+Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
+Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+Cc: Ralf Baechle <ralf@linux-mips.org>
+Cc: John Crispin <john@phrozen.org>
+Cc: linux-mips@linux-mips.org
+Cc: <stable@vger.kernel.org> # 4.14+
+Patchwork: https://patchwork.linux-mips.org/patch/18816/
+Signed-off-by: James Hogan <jhogan@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/mips/lantiq/xway/sysctrl.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/mips/lantiq/xway/sysctrl.c
++++ b/arch/mips/lantiq/xway/sysctrl.c
+@@ -562,7 +562,7 @@ void __init ltq_soc_init(void)
+ } else {
+ clkdev_add_static(ltq_danube_cpu_hz(), ltq_danube_fpi_hz(),
+ ltq_danube_fpi_hz(), ltq_danube_pp32_hz());
+- clkdev_add_pmu("1f203018.usb2-phy", "ctrl", 1, 0, PMU_USB0);
++ clkdev_add_pmu("1e101000.usb", "otg", 1, 0, PMU_USB0);
+ clkdev_add_pmu("1f203018.usb2-phy", "phy", 1, 0, PMU_USB0_P);
+ clkdev_add_pmu("1e103000.sdio", NULL, 1, 0, PMU_SDIO);
+ clkdev_add_pmu("1e103100.deu", NULL, 1, 0, PMU_DEU);
--- /dev/null
+From a63d706ea719190a79a6c769e898f70680044d3e Mon Sep 17 00:00:00 2001
+From: NeilBrown <neil@brown.name>
+Date: Wed, 21 Mar 2018 14:02:10 +1100
+Subject: MIPS: ralink: Fix booting on MT7621
+
+From: NeilBrown <neil@brown.name>
+
+commit a63d706ea719190a79a6c769e898f70680044d3e upstream.
+
+Since commit 3af5a67c86a3 ("MIPS: Fix early CM probing") the MT7621 has
+not been able to boot.
+
+This commit caused mips_cm_probe() to be called before
+mt7621.c::proc_soc_init().
+
+prom_soc_init() has a comment explaining that mips_cm_probe() "wipes out
+the bootloader config" and means that configuration registers are no
+longer available. It has some code to re-enable this config.
+
+Before this re-enable code is run, the sysc register cannot be read, so
+when SYSC_REG_CHIP_NAME0 is read, a garbage value is returned and
+panic() is called.
+
+If we move the config-repair code to the top of prom_soc_init(), the
+registers can be read and boot can proceed.
+
+Very occasionally, the first register read after the reconfiguration
+returns garbage, so add a call to __sync().
+
+Fixes: 3af5a67c86a3 ("MIPS: Fix early CM probing")
+Signed-off-by: NeilBrown <neil@brown.name>
+Reviewed-by: Matt Redfearn <matt.redfearn@mips.com>
+Cc: John Crispin <john@phrozen.org>
+Cc: Ralf Baechle <ralf@linux-mips.org>
+Cc: linux-mips@linux-mips.org
+Cc: <stable@vger.kernel.org> # 4.5+
+Patchwork: https://patchwork.linux-mips.org/patch/18859/
+Signed-off-by: James Hogan <jhogan@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/mips/ralink/mt7621.c | 42 ++++++++++++++++++++++--------------------
+ 1 file changed, 22 insertions(+), 20 deletions(-)
+
+--- a/arch/mips/ralink/mt7621.c
++++ b/arch/mips/ralink/mt7621.c
+@@ -170,6 +170,28 @@ void prom_soc_init(struct ralink_soc_inf
+ u32 n1;
+ u32 rev;
+
++ /* Early detection of CMP support */
++ mips_cm_probe();
++ mips_cpc_probe();
++
++ if (mips_cps_numiocu(0)) {
++ /*
++ * mips_cm_probe() wipes out bootloader
++ * config for CM regions and we have to configure them
++ * again. This SoC cannot talk to pamlbus devices
++ * witout proper iocu region set up.
++ *
++ * FIXME: it would be better to do this with values
++ * from DT, but we need this very early because
++ * without this we cannot talk to pretty much anything
++ * including serial.
++ */
++ write_gcr_reg0_base(MT7621_PALMBUS_BASE);
++ write_gcr_reg0_mask(~MT7621_PALMBUS_SIZE |
++ CM_GCR_REGn_MASK_CMTGT_IOCU0);
++ __sync();
++ }
++
+ n0 = __raw_readl(sysc + SYSC_REG_CHIP_NAME0);
+ n1 = __raw_readl(sysc + SYSC_REG_CHIP_NAME1);
+
+@@ -194,26 +216,6 @@ void prom_soc_init(struct ralink_soc_inf
+
+ rt2880_pinmux_data = mt7621_pinmux_data;
+
+- /* Early detection of CMP support */
+- mips_cm_probe();
+- mips_cpc_probe();
+-
+- if (mips_cps_numiocu(0)) {
+- /*
+- * mips_cm_probe() wipes out bootloader
+- * config for CM regions and we have to configure them
+- * again. This SoC cannot talk to pamlbus devices
+- * witout proper iocu region set up.
+- *
+- * FIXME: it would be better to do this with values
+- * from DT, but we need this very early because
+- * without this we cannot talk to pretty much anything
+- * including serial.
+- */
+- write_gcr_reg0_base(MT7621_PALMBUS_BASE);
+- write_gcr_reg0_mask(~MT7621_PALMBUS_SIZE |
+- CM_GCR_REGn_MASK_CMTGT_IOCU0);
+- }
+
+ if (!register_cps_smp_ops())
+ return;
--- /dev/null
+From 891731f6a5dbe508d12443175a7e166a2fba616a Mon Sep 17 00:00:00 2001
+From: NeilBrown <neil@brown.name>
+Date: Tue, 20 Mar 2018 19:29:51 +1100
+Subject: MIPS: ralink: Remove ralink_halt()
+
+From: NeilBrown <neil@brown.name>
+
+commit 891731f6a5dbe508d12443175a7e166a2fba616a upstream.
+
+ralink_halt() does nothing that machine_halt() doesn't already do, so it
+adds no value.
+
+It actually causes incorrect behaviour due to the "unreachable()" at the
+end. This tells the compiler that the end of the function will never be
+reached, which isn't true. The compiler responds by not adding a
+'return' instruction, so control simply moves on to whatever bytes come
+afterwards in memory. In my tested, that was the ralink_restart()
+function. This means that an attempt to 'halt' the machine would
+actually cause a reboot.
+
+So remove ralink_halt() so that a 'halt' really does halt.
+
+Fixes: c06e836ada59 ("MIPS: ralink: adds reset code")
+Signed-off-by: NeilBrown <neil@brown.name>
+Cc: John Crispin <john@phrozen.org>
+Cc: Ralf Baechle <ralf@linux-mips.org>
+Cc: linux-mips@linux-mips.org
+Cc: <stable@vger.kernel.org> # 3.9+
+Patchwork: https://patchwork.linux-mips.org/patch/18851/
+Signed-off-by: James Hogan <jhogan@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/mips/ralink/reset.c | 7 -------
+ 1 file changed, 7 deletions(-)
+
+--- a/arch/mips/ralink/reset.c
++++ b/arch/mips/ralink/reset.c
+@@ -96,16 +96,9 @@ static void ralink_restart(char *command
+ unreachable();
+ }
+
+-static void ralink_halt(void)
+-{
+- local_irq_disable();
+- unreachable();
+-}
+-
+ static int __init mips_reboot_setup(void)
+ {
+ _machine_restart = ralink_restart;
+- _machine_halt = ralink_halt;
+
+ return 0;
+ }
--- /dev/null
+From e74ef2194b41ba5e511fab29fe5ff00e72d2f42a Mon Sep 17 00:00:00 2001
+From: Bastian Stender <bst@pengutronix.de>
+Date: Thu, 8 Mar 2018 15:08:11 +0100
+Subject: mmc: block: fix updating ext_csd caches on ioctl call
+
+From: Bastian Stender <bst@pengutronix.de>
+
+commit e74ef2194b41ba5e511fab29fe5ff00e72d2f42a upstream.
+
+PARTITION_CONFIG is cached in mmc_card->ext_csd.part_config and the
+currently active partition in mmc_blk_data->part_curr. These caches do
+not always reflect changes if the ioctl call modifies the
+PARTITION_CONFIG registers, e.g. by changing BOOT_PARTITION_ENABLE.
+
+Write the PARTITION_CONFIG value extracted from the ioctl call to the
+cache and update the currently active partition accordingly. This
+ensures that the user space cannot change the values behind the
+kernel's back. The next call to mmc_blk_part_switch() will operate on
+the data set by the ioctl and reflect the changes appropriately.
+
+Signed-off-by: Bastian Stender <bst@pengutronix.de>
+Signed-off-by: Jan Luebbe <jlu@pengutronix.de>
+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/core/block.c | 19 +++++++++++++++++++
+ 1 file changed, 19 insertions(+)
+
+--- a/drivers/mmc/core/block.c
++++ b/drivers/mmc/core/block.c
+@@ -65,6 +65,7 @@ MODULE_ALIAS("mmc:block");
+ #define MMC_BLK_TIMEOUT_MS (10 * 60 * 1000) /* 10 minute timeout */
+ #define MMC_SANITIZE_REQ_TIMEOUT 240000
+ #define MMC_EXTRACT_INDEX_FROM_ARG(x) ((x & 0x00FF0000) >> 16)
++#define MMC_EXTRACT_VALUE_FROM_ARG(x) ((x & 0x0000FF00) >> 8)
+
+ #define mmc_req_rel_wr(req) ((req->cmd_flags & REQ_FUA) && \
+ (rq_data_dir(req) == WRITE))
+@@ -539,6 +540,24 @@ static int __mmc_blk_ioctl_cmd(struct mm
+ }
+
+ /*
++ * Make sure the cache of the PARTITION_CONFIG register and
++ * PARTITION_ACCESS bits is updated in case the ioctl ext_csd write
++ * changed it successfully.
++ */
++ if ((MMC_EXTRACT_INDEX_FROM_ARG(cmd.arg) == EXT_CSD_PART_CONFIG) &&
++ (cmd.opcode == MMC_SWITCH)) {
++ struct mmc_blk_data *main_md = dev_get_drvdata(&card->dev);
++ u8 value = MMC_EXTRACT_VALUE_FROM_ARG(cmd.arg);
++
++ /*
++ * Update cache so the next mmc_blk_part_switch call operates
++ * on up-to-date data.
++ */
++ card->ext_csd.part_config = value;
++ main_md->part_curr = value & EXT_CSD_PART_CONFIG_ACC_MASK;
++ }
++
++ /*
+ * According to the SD specs, some commands require a delay after
+ * issuing the command.
+ */
--- /dev/null
+From dbe7dc6b9b28f5b012b0bedc372aa0c52521f3e4 Mon Sep 17 00:00:00 2001
+From: Dirk Behme <dirk.behme@de.bosch.com>
+Date: Wed, 14 Mar 2018 14:50:09 +0000
+Subject: mmc: core: Disable HPI for certain Micron (Numonyx) eMMC cards
+
+From: Dirk Behme <dirk.behme@de.bosch.com>
+
+commit dbe7dc6b9b28f5b012b0bedc372aa0c52521f3e4 upstream.
+
+Certain Micron eMMC v4.5 cards might get broken when HPI feature is used
+and hence this patch disables the HPI feature for such buggy cards.
+
+In U-Boot, these cards are reported as
+
+Manufacturer: Micron (ID: 0xFE)
+OEM: 0x4E
+Name: MMC32G
+Revision: 19 (0x13)
+Serial: 959241022 Manufact. date: 8/2015 (0x82) CRC: 0x00
+Tran Speed: 52000000
+Rd Block Len: 512
+MMC version 4.5
+High Capacity: Yes
+Capacity: 29.1 GiB
+Boot Partition Size: 16 MiB
+Bus Width: 8-bit
+
+According to JEDEC JEP106 manufacturer 0xFE is Numonyx, which was bought by
+Micron.
+
+Signed-off-by: Dirk Behme <dirk.behme@de.bosch.com>
+Signed-off-by: Mark Craske <Mark_Craske@mentor.com>
+Cc: <stable@vger.kernel.org> # 4.8+
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/core/card.h | 1 +
+ drivers/mmc/core/quirks.h | 6 ++++++
+ 2 files changed, 7 insertions(+)
+
+--- a/drivers/mmc/core/card.h
++++ b/drivers/mmc/core/card.h
+@@ -82,6 +82,7 @@ struct mmc_fixup {
+ #define CID_MANFID_APACER 0x27
+ #define CID_MANFID_KINGSTON 0x70
+ #define CID_MANFID_HYNIX 0x90
++#define CID_MANFID_NUMONYX 0xFE
+
+ #define END_FIXUP { NULL }
+
+--- a/drivers/mmc/core/quirks.h
++++ b/drivers/mmc/core/quirks.h
+@@ -109,6 +109,12 @@ static const struct mmc_fixup mmc_ext_cs
+ */
+ MMC_FIXUP_EXT_CSD_REV(CID_NAME_ANY, CID_MANFID_HYNIX,
+ 0x014a, add_quirk, MMC_QUIRK_BROKEN_HPI, 5),
++ /*
++ * Certain Micron (Numonyx) eMMC 4.5 cards might get broken when HPI
++ * feature is used so disable the HPI feature for such buggy cards.
++ */
++ MMC_FIXUP_EXT_CSD_REV(CID_NAME_ANY, CID_MANFID_NUMONYX,
++ 0x014e, add_quirk, MMC_QUIRK_BROKEN_HPI, 6),
+
+ END_FIXUP
+ };
--- /dev/null
+From c658dc58c7eaa8569ceb0edd1ddbdfda84fe8aa5 Mon Sep 17 00:00:00 2001
+From: Adrian Hunter <adrian.hunter@intel.com>
+Date: Thu, 15 Mar 2018 11:22:28 +0200
+Subject: mmc: core: Fix tracepoint print of blk_addr and blksz
+
+From: Adrian Hunter <adrian.hunter@intel.com>
+
+commit c658dc58c7eaa8569ceb0edd1ddbdfda84fe8aa5 upstream.
+
+Swap the positions of blk_addr and blksz in the tracepoint print arguments
+so that they match the print format.
+
+Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
+Fixes: d2f82254e4e8 ("mmc: core: Add members to mmc_request and mmc_data for CQE's")
+Cc: <stable@vger.kernel.org> # 4.14+
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ include/trace/events/mmc.h | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/include/trace/events/mmc.h
++++ b/include/trace/events/mmc.h
+@@ -86,8 +86,8 @@ TRACE_EVENT(mmc_request_start,
+ __entry->stop_flags, __entry->stop_retries,
+ __entry->sbc_opcode, __entry->sbc_arg,
+ __entry->sbc_flags, __entry->sbc_retries,
+- __entry->blocks, __entry->blk_addr,
+- __entry->blksz, __entry->data_flags, __entry->tag,
++ __entry->blocks, __entry->blksz,
++ __entry->blk_addr, __entry->data_flags, __entry->tag,
+ __entry->can_retune, __entry->doing_retune,
+ __entry->retune_now, __entry->need_retune,
+ __entry->hold_retune, __entry->retune_period)
--- /dev/null
+From e22842dd64bf86753d3f2b6ea474d73fc1e6ca24 Mon Sep 17 00:00:00 2001
+From: Jaehoon Chung <jh80.chung@samsung.com>
+Date: Fri, 9 Mar 2018 15:10:21 +0900
+Subject: mmc: dw_mmc: exynos: fix the suspend/resume issue for exynos5433
+
+From: Jaehoon Chung <jh80.chung@samsung.com>
+
+commit e22842dd64bf86753d3f2b6ea474d73fc1e6ca24 upstream.
+
+Before enabling the clock, dwmmc exynos driver is trying to access the
+register. Then the kernel panic can be occurred.
+
+Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
+Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
+Tested-by: Chanwoo Choi <cw00.choi@samsung.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/dw_mmc-exynos.c | 8 +++++++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+--- a/drivers/mmc/host/dw_mmc-exynos.c
++++ b/drivers/mmc/host/dw_mmc-exynos.c
+@@ -165,9 +165,15 @@ static void dw_mci_exynos_set_clksel_tim
+ static int dw_mci_exynos_runtime_resume(struct device *dev)
+ {
+ struct dw_mci *host = dev_get_drvdata(dev);
++ int ret;
++
++ ret = dw_mci_runtime_resume(dev);
++ if (ret)
++ return ret;
+
+ dw_mci_exynos_config_smu(host);
+- return dw_mci_runtime_resume(dev);
++
++ return ret;
+ }
+
+ /**
--- /dev/null
+From 47b7de2f6c18f75d1f2716efe752cba43f32a626 Mon Sep 17 00:00:00 2001
+From: Evgeniy Didin <Evgeniy.Didin@synopsys.com>
+Date: Wed, 14 Mar 2018 22:30:51 +0300
+Subject: mmc: dw_mmc: fix falling from idmac to PIO mode when dw_mci_reset occurs
+
+From: Evgeniy Didin <Evgeniy.Didin@synopsys.com>
+
+commit 47b7de2f6c18f75d1f2716efe752cba43f32a626 upstream.
+
+It was found that in IDMAC mode after soft-reset driver switches
+to PIO mode.
+
+That's what happens in case of DTO timeout overflow calculation failure:
+1. soft-reset is called
+2. driver restarts dma
+3. descriptors states are checked, one of descriptor is owned by the IDMAC.
+4. driver can't use DMA and then switches to PIO mode.
+
+Failure was already fixed in:
+https://www.spinics.net/lists/linux-mmc/msg48125.html.
+
+Behaviour while soft-reset is not something we except or
+even want to happen. So we switch from dw_mci_idmac_reset
+to dw_mci_idmac_init, so descriptors are cleaned before starting dma.
+
+And while at it explicitly zero des0 which otherwise might
+contain garbage as being allocated by dmam_alloc_coherent().
+
+Signed-off-by: Evgeniy Didin <Evgeniy.Didin@synopsys.com>
+Cc: Jaehoon Chung <jh80.chung@samsung.com>
+Cc: Ulf Hansson <ulf.hansson@linaro.org>
+Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
+Cc: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
+Cc: Shawn Lin <shawn.lin@rock-chips.com>
+Cc: Alexey Brodkin <abrodkin@synopsys.com>
+Cc: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
+Cc: linux-snps-arc@lists.infradead.org
+Cc: <stable@vger.kernel.org> # 4.4+
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/host/dw_mmc.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/drivers/mmc/host/dw_mmc.c
++++ b/drivers/mmc/host/dw_mmc.c
+@@ -564,6 +564,7 @@ static int dw_mci_idmac_init(struct dw_m
+ (sizeof(struct idmac_desc_64addr) *
+ (i + 1))) >> 32;
+ /* Initialize reserved and buffer size fields to "0" */
++ p->des0 = 0;
+ p->des1 = 0;
+ p->des2 = 0;
+ p->des3 = 0;
+@@ -586,6 +587,7 @@ static int dw_mci_idmac_init(struct dw_m
+ i++, p++) {
+ p->des3 = cpu_to_le32(host->sg_dma +
+ (sizeof(struct idmac_desc) * (i + 1)));
++ p->des0 = 0;
+ p->des1 = 0;
+ }
+
+@@ -1801,8 +1803,8 @@ static bool dw_mci_reset(struct dw_mci *
+ }
+
+ if (host->use_dma == TRANS_MODE_IDMAC)
+- /* It is also recommended that we reset and reprogram idmac */
+- dw_mci_idmac_reset(host);
++ /* It is also required that we reinit idmac */
++ dw_mci_idmac_init(host);
+
+ ret = true;
+
--- /dev/null
+From c7151602255a36ba07c84fe2baeef846fdb988b8 Mon Sep 17 00:00:00 2001
+From: Evgeniy Didin <Evgeniy.Didin@synopsys.com>
+Date: Wed, 28 Feb 2018 14:53:18 +0300
+Subject: mmc: dw_mmc: Fix the DTO/CTO timeout overflow calculation for 32-bit systems
+
+From: Evgeniy Didin <Evgeniy.Didin@synopsys.com>
+
+commit c7151602255a36ba07c84fe2baeef846fdb988b8 upstream.
+
+The commit 9d9491a7da2a ("mmc: dw_mmc: Fix the DTO timeout calculation")
+and commit 4c2357f57dd5 ("mmc: dw_mmc: Fix the CTO timeout calculation")
+made changes, which cause multiply overflow for 32-bit systems. The broken
+timeout calculations leads to unexpected ETIMEDOUT errors and causes
+stacktrace splat (such as below) during normal data exchange with SD-card.
+
+| Running : 4M-check-reassembly-tcp-cmykw2-rotatew2.out -v0 -w1
+| - Info: Finished target initialization.
+| mmcblk0: error -110 transferring data, sector 320544, nr 2048, cmd
+| response 0x900, card status 0x0
+
+DIV_ROUND_UP_ULL helps to escape usage of __udivdi3() from libgcc and so
+code gets compiled on all 32-bit platforms as opposed to usage of
+DIV_ROUND_UP when we may only compile stuff on a very few arches.
+
+Lets cast this multiply to u64 type to prevent the overflow.
+
+Fixes: 9d9491a7da2a ("mmc: dw_mmc: Fix the DTO timeout calculation")
+Fixes: 4c2357f57dd5 ("mmc: dw_mmc: Fix the CTO timeout calculation")
+Tested-by: Vineet Gupta <Vineet.Gupta1@synopsys.com>
+Reported-by: Vineet Gupta <Vineet.Gupta1@synopsys.com> # ARC STAR 9001306872 HSDK, sdio: board crashes when copying big files
+Signed-off-by: Evgeniy Didin <Evgeniy.Didin@synopsys.com>
+Cc: <stable@vger.kernel.org> # 4.14
+Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
+Reviewed-by: Douglas Anderson <dianders@chromium.org>
+Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
+Reviewed-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
+Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/host/dw_mmc.c | 9 ++++++---
+ 1 file changed, 6 insertions(+), 3 deletions(-)
+
+--- a/drivers/mmc/host/dw_mmc.c
++++ b/drivers/mmc/host/dw_mmc.c
+@@ -413,7 +413,9 @@ static inline void dw_mci_set_cto(struct
+ cto_div = (mci_readl(host, CLKDIV) & 0xff) * 2;
+ if (cto_div == 0)
+ cto_div = 1;
+- cto_ms = DIV_ROUND_UP(MSEC_PER_SEC * cto_clks * cto_div, host->bus_hz);
++
++ cto_ms = DIV_ROUND_UP_ULL((u64)MSEC_PER_SEC * cto_clks * cto_div,
++ host->bus_hz);
+
+ /* add a bit spare time */
+ cto_ms += 10;
+@@ -1947,8 +1949,9 @@ static void dw_mci_set_drto(struct dw_mc
+ drto_div = (mci_readl(host, CLKDIV) & 0xff) * 2;
+ if (drto_div == 0)
+ drto_div = 1;
+- drto_ms = DIV_ROUND_UP(MSEC_PER_SEC * drto_clks * drto_div,
+- host->bus_hz);
++
++ drto_ms = DIV_ROUND_UP_ULL((u64)MSEC_PER_SEC * drto_clks * drto_div,
++ host->bus_hz);
+
+ /* add a bit spare time */
+ drto_ms += 10;
--- /dev/null
+From 1903be8222b7c278ca897c129ce477c1dd6403a8 Mon Sep 17 00:00:00 2001
+From: Hans de Goede <hdegoede@redhat.com>
+Date: Fri, 2 Mar 2018 11:36:33 +0100
+Subject: PCI: Add function 1 DMA alias quirk for Highpoint RocketRAID 644L
+
+From: Hans de Goede <hdegoede@redhat.com>
+
+commit 1903be8222b7c278ca897c129ce477c1dd6403a8 upstream.
+
+The Highpoint RocketRAID 644L uses a Marvel 88SE9235 controller, as with
+other Marvel controllers this needs a function 1 DMA alias quirk.
+
+Note the RocketRAID 642L uses the same Marvel 88SE9235 controller and
+already is listed with a function 1 DMA alias quirk.
+
+Cc: stable@vger.kernel.org
+BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1534106
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Acked-by: Bjorn Helgaas <bhelgaas@google.com>
+Signed-off-by: Tejun Heo <tj@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/pci/quirks.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/pci/quirks.c
++++ b/drivers/pci/quirks.c
+@@ -3899,6 +3899,8 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_M
+ quirk_dma_func1_alias);
+ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_TTI, 0x0642,
+ quirk_dma_func1_alias);
++DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_TTI, 0x0645,
++ quirk_dma_func1_alias);
+ /* https://bugs.gentoo.org/show_bug.cgi?id=497630 */
+ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_JMICRON,
+ PCI_DEVICE_ID_JMICRON_JMB388_ESD,
--- /dev/null
+From f3f134f5260ae9ee1f5a4d0a8cc625c6c77655b4 Mon Sep 17 00:00:00 2001
+From: Leon Romanovsky <leonro@mellanox.com>
+Date: Mon, 12 Mar 2018 21:26:37 +0200
+Subject: RDMA/mlx5: Fix crash while accessing garbage pointer and freed memory
+
+From: Leon Romanovsky <leonro@mellanox.com>
+
+commit f3f134f5260ae9ee1f5a4d0a8cc625c6c77655b4 upstream.
+
+The failure in rereg_mr flow caused to set garbage value (error value)
+into mr->umem pointer. This pointer is accessed at the release stage
+and it causes to the following crash.
+
+There is not enough to simply change umem to point to NULL, because the
+MR struct is needed to be accessed during MR deregistration phase, so
+delay kfree too.
+
+[ 6.237617] BUG: unable to handle kernel NULL pointer dereference a 0000000000000228
+[ 6.238756] IP: ib_dereg_mr+0xd/0x30
+[ 6.239264] PGD 80000000167eb067 P4D 80000000167eb067 PUD 167f9067 PMD 0
+[ 6.240320] Oops: 0000 [#1] SMP PTI
+[ 6.240782] CPU: 0 PID: 367 Comm: dereg Not tainted 4.16.0-rc1-00029-gc198fafe0453 #183
+[ 6.242120] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014
+[ 6.244504] RIP: 0010:ib_dereg_mr+0xd/0x30
+[ 6.245253] RSP: 0018:ffffaf5d001d7d68 EFLAGS: 00010246
+[ 6.246100] RAX: 0000000000000000 RBX: ffff95d4172daf00 RCX: 0000000000000000
+[ 6.247414] RDX: 00000000ffffffff RSI: 0000000000000001 RDI: ffff95d41a317600
+[ 6.248591] RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000
+[ 6.249810] R10: ffff95d417033c10 R11: 0000000000000000 R12: ffff95d4172c3a80
+[ 6.251121] R13: ffff95d4172c3720 R14: ffff95d4172c3a98 R15: 00000000ffffffff
+[ 6.252437] FS: 0000000000000000(0000) GS:ffff95d41fc00000(0000) knlGS:0000000000000000
+[ 6.253887] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+[ 6.254814] CR2: 0000000000000228 CR3: 00000000172b4000 CR4: 00000000000006b0
+[ 6.255943] Call Trace:
+[ 6.256368] remove_commit_idr_uobject+0x1b/0x80
+[ 6.257118] uverbs_cleanup_ucontext+0xe4/0x190
+[ 6.257855] ib_uverbs_cleanup_ucontext.constprop.14+0x19/0x40
+[ 6.258857] ib_uverbs_close+0x2a/0x100
+[ 6.259494] __fput+0xca/0x1c0
+[ 6.259938] task_work_run+0x84/0xa0
+[ 6.260519] do_exit+0x312/0xb40
+[ 6.261023] ? __do_page_fault+0x24d/0x490
+[ 6.261707] do_group_exit+0x3a/0xa0
+[ 6.262267] SyS_exit_group+0x10/0x10
+[ 6.262802] do_syscall_64+0x75/0x180
+[ 6.263391] entry_SYSCALL_64_after_hwframe+0x21/0x86
+[ 6.264253] RIP: 0033:0x7f1b39c49488
+[ 6.264827] RSP: 002b:00007ffe2de05b68 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
+[ 6.266049] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1b39c49488
+[ 6.267187] RDX: 0000000000000000 RSI: 000000000000003c RDI: 0000000000000000
+[ 6.268377] RBP: 00007f1b39f258e0 R08: 00000000000000e7 R09: ffffffffffffff98
+[ 6.269640] R10: 00007f1b3a147260 R11: 0000000000000246 R12: 00007f1b39f258e0
+[ 6.270783] R13: 00007f1b39f2ac20 R14: 0000000000000000 R15: 0000000000000000
+[ 6.271943] Code: 74 07 31 d2 e9 25 d8 6c 00 b8 da ff ff ff c3 0f 1f
+44 00 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 8b 07 53 48 8b
+5f 08 <48> 8b 80 28 02 00 00 e8 f7 d7 6c 00 85 c0 75 04 3e ff 4b 18 5b
+[ 6.274927] RIP: ib_dereg_mr+0xd/0x30 RSP: ffffaf5d001d7d68
+[ 6.275760] CR2: 0000000000000228
+[ 6.276200] ---[ end trace a35641f1c474bd20 ]---
+
+Fixes: e126ba97dba9 ("mlx5: Add driver for Mellanox Connect-IB adapters")
+Cc: syzkaller <syzkaller@googlegroups.com>
+Cc: <stable@vger.kernel.org>
+Reported-by: Noa Osherovich <noaos@mellanox.com>
+Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
+Signed-off-by: Doug Ledford <dledford@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/infiniband/hw/mlx5/mr.c | 12 ++++++++----
+ 1 file changed, 8 insertions(+), 4 deletions(-)
+
+--- a/drivers/infiniband/hw/mlx5/mr.c
++++ b/drivers/infiniband/hw/mlx5/mr.c
+@@ -838,7 +838,8 @@ static int mr_umem_get(struct ib_pd *pd,
+ *umem = ib_umem_get(pd->uobject->context, start, length,
+ access_flags, 0);
+ err = PTR_ERR_OR_ZERO(*umem);
+- if (err < 0) {
++ if (err) {
++ *umem = NULL;
+ mlx5_ib_err(dev, "umem get failed (%d)\n", err);
+ return err;
+ }
+@@ -1415,6 +1416,7 @@ int mlx5_ib_rereg_user_mr(struct ib_mr *
+ if (err) {
+ mlx5_ib_warn(dev, "Failed to rereg UMR\n");
+ ib_umem_release(mr->umem);
++ mr->umem = NULL;
+ clean_mr(dev, mr);
+ return err;
+ }
+@@ -1498,14 +1500,11 @@ static int clean_mr(struct mlx5_ib_dev *
+ u32 key = mr->mmkey.key;
+
+ err = destroy_mkey(dev, mr);
+- kfree(mr);
+ if (err) {
+ mlx5_ib_warn(dev, "failed to destroy mkey 0x%x (%d)\n",
+ key, err);
+ return err;
+ }
+- } else {
+- mlx5_mr_cache_free(dev, mr);
+ }
+
+ return 0;
+@@ -1548,6 +1547,11 @@ static int dereg_mr(struct mlx5_ib_dev *
+ atomic_sub(npages, &dev->mdev->priv.reg_pages);
+ }
+
++ if (!mr->allocated_from_cache)
++ kfree(mr);
++ else
++ mlx5_mr_cache_free(dev, mr);
++
+ return 0;
+ }
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
