--- /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
+@@ -538,7 +538,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 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
+@@ -3261,8 +3261,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 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
+@@ -369,7 +369,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,
+@@ -377,7 +377,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 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
+@@ -912,8 +912,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);
+@@ -997,9 +999,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 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
+@@ -657,7 +657,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)
+ return err;
+
+--- a/drivers/iio/pressure/st_pressure_core.c
++++ b/drivers/iio/pressure/st_pressure_core.c
+@@ -469,7 +469,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)
+ return err;
+
--- /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 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
+@@ -619,6 +619,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;
+@@ -640,6 +641,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;
+ }
+
+@@ -2807,8 +2809,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 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
+@@ -3631,6 +3631,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,
projects / thirdparty / kernel / stable-queue.git / commitdiff
