--- /dev/null
+From 279e17ae81c17b40ae7a6c9e10f386a7aac7aa55 Mon Sep 17 00:00:00 2001
+From: Christian Engelmayer <cengelma@gmx.at>
+Date: Sat, 7 Feb 2015 23:40:52 +0100
+Subject: ASoC: Intel: sst: Fix firmware name size handling
+
+From: Christian Engelmayer <cengelma@gmx.at>
+
+commit 279e17ae81c17b40ae7a6c9e10f386a7aac7aa55 upstream.
+
+Function sst_acpi_probe() uses plain strcpy for setting member firmware_name
+of a struct intel_sst_drv from member firmware of a struct sst_machines.
+Thereby the destination array has got a length of 20 byte while the source may
+hold 32 byte. Since eg. commit 64b9c90b8600 ("ASoC: Intel: Fix BYTCR firmware
+name") increased strings from "fw_sst_0f28.bin" to "intel/fw_sst_0f28.bin"
+there is an actual possibility that the 20 byte array at the end of struct
+intel_sst_drv is overrun.
+
+Thus increase the size of the destination and use the same define for both
+structs. Detected by Coverity CID 1260087.
+
+Signed-off-by: Christian Engelmayer <cengelma@gmx.at>
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/soc/intel/sst/sst.h | 3 ++-
+ sound/soc/intel/sst/sst_acpi.c | 2 +-
+ 2 files changed, 3 insertions(+), 2 deletions(-)
+
+--- a/sound/soc/intel/sst/sst.h
++++ b/sound/soc/intel/sst/sst.h
+@@ -58,6 +58,7 @@ enum sst_algo_ops {
+ #define SST_BLOCK_TIMEOUT 1000
+
+ #define FW_SIGNATURE_SIZE 4
++#define FW_NAME_SIZE 32
+
+ /* stream states */
+ enum sst_stream_states {
+@@ -426,7 +427,7 @@ struct intel_sst_drv {
+ * Holder for firmware name. Due to async call it needs to be
+ * persistent till worker thread gets called
+ */
+- char firmware_name[20];
++ char firmware_name[FW_NAME_SIZE];
+ };
+
+ /* misc definitions */
+--- a/sound/soc/intel/sst/sst_acpi.c
++++ b/sound/soc/intel/sst/sst_acpi.c
+@@ -47,7 +47,7 @@ struct sst_machines {
+ char board[32];
+ char machine[32];
+ void (*machine_quirk)(void);
+- char firmware[32];
++ char firmware[FW_NAME_SIZE];
+ struct sst_platform_info *pdata;
+
+ };
--- /dev/null
+From 7331ea474e9e7a348541c207bdb6aa518c6403f4 Mon Sep 17 00:00:00 2001
+From: Lars-Peter Clausen <lars@metafoo.de>
+Date: Thu, 15 Jan 2015 12:52:01 +0100
+Subject: ASoC: mioa701_wm9713: Fix speaker event
+
+From: Lars-Peter Clausen <lars@metafoo.de>
+
+commit 7331ea474e9e7a348541c207bdb6aa518c6403f4 upstream.
+
+Commit f6b2a04590bb ("ASoC: pxa: mioa701_wm9713: Convert to table based DAPM
+setup") converted the driver to register the board level DAPM elements with
+the card's DAPM context rather than the CODEC's DAPM context. The change
+overlooked that the speaker widget event callback accesses the widget's
+codec field which is only valid if the widget has been registered in a CODEC
+DAPM context. This patch modifies the callback to take an alternative route
+to get the CODEC.
+
+Fixes: f6b2a04590bb ("ASoC: pxa: mioa701_wm9713: Convert to table based DAPM
+setup")
+Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/soc/pxa/mioa701_wm9713.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/sound/soc/pxa/mioa701_wm9713.c
++++ b/sound/soc/pxa/mioa701_wm9713.c
+@@ -81,7 +81,7 @@ static int rear_amp_power(struct snd_soc
+ static int rear_amp_event(struct snd_soc_dapm_widget *widget,
+ struct snd_kcontrol *kctl, int event)
+ {
+- struct snd_soc_codec *codec = widget->codec;
++ struct snd_soc_codec *codec = widget->dapm->card->rtd[0].codec;
+
+ return rear_amp_power(codec, SND_SOC_DAPM_EVENT_ON(event));
+ }
--- /dev/null
+From 92b133f251b5f914f3ed28bc83e5b7a40d4e22ed Mon Sep 17 00:00:00 2001
+From: Bard Liao <bardliao@realtek.com>
+Date: Mon, 9 Feb 2015 14:41:50 +0800
+Subject: ASoC: rt5670: Set use_single_rw flag for regmap
+
+From: Bard Liao <bardliao@realtek.com>
+
+commit 92b133f251b5f914f3ed28bc83e5b7a40d4e22ed upstream.
+
+RT5670 doesn't support auto incrementing writes so driver should
+set the use_single_rw flag for regmap.
+
+Signed-off-by: Bard Liao <bardliao@realtek.com>
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/soc/codecs/rt5670.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/sound/soc/codecs/rt5670.c
++++ b/sound/soc/codecs/rt5670.c
+@@ -2522,6 +2522,7 @@ static struct snd_soc_codec_driver soc_c
+ static const struct regmap_config rt5670_regmap = {
+ .reg_bits = 8,
+ .val_bits = 16,
++ .use_single_rw = true,
+ .max_register = RT5670_VENDOR_ID2 + 1 + (ARRAY_SIZE(rt5670_ranges) *
+ RT5670_PR_SPACING),
+ .volatile_reg = rt5670_volatile_register,
--- /dev/null
+From 4c121129c9dcb43b33d1cd568c8f2636e72597b0 Mon Sep 17 00:00:00 2001
+From: Arnd Bergmann <arnd@arndb.de>
+Date: Wed, 28 Jan 2015 22:31:30 +0100
+Subject: ASoC: rt5677: fix SPI dependency
+
+From: Arnd Bergmann <arnd@arndb.de>
+
+commit 4c121129c9dcb43b33d1cd568c8f2636e72597b0 upstream.
+
+The rt5677 codec has gained code that requires SPI to work correctly,
+but there is no provision in Kconfig to prevent the driver from
+being used when SPI is disabled or a loadable module, resulting
+in this build error:
+
+sound/built-in.o: In function `rt5677_spi_write':
+:(.text+0xa7ba0): undefined reference to `spi_sync'
+sound/built-in.o: In function `rt5677_spi_driver_init':
+:(.init.text+0x253c): undefined reference to `spi_register_driver'
+
+ERROR: "spi_sync" [sound/soc/codecs/snd-soc-rt5677-spi.ko] undefined!
+ERROR: "spi_register_driver" [sound/soc/codecs/snd-soc-rt5677-spi.ko] undefined!
+
+This makes the SPI portion of the driver depend on the SPI subsystem,
+and disables the function that uses SPI for firmware download if SPI
+is disabled. The latter may not be the correct solution, but I could
+not come up with a better one.
+
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Fixes: af48f1d08a54741 ("ASoC: rt5677: Support DSP function for VAD application")
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/soc/codecs/Kconfig | 2 +-
+ sound/soc/codecs/rt5677.c | 3 +++
+ 2 files changed, 4 insertions(+), 1 deletion(-)
+
+--- a/sound/soc/codecs/Kconfig
++++ b/sound/soc/codecs/Kconfig
+@@ -525,7 +525,7 @@ config SND_SOC_RT5677
+
+ config SND_SOC_RT5677_SPI
+ tristate
+- default SND_SOC_RT5677
++ default SND_SOC_RT5677 && SPI
+
+ #Freescale sgtl5000 codec
+ config SND_SOC_SGTL5000
+--- a/sound/soc/codecs/rt5677.c
++++ b/sound/soc/codecs/rt5677.c
+@@ -702,6 +702,9 @@ static int rt5677_set_dsp_vad(struct snd
+ static bool activity;
+ int ret;
+
++ if (!IS_ENABLED(CONFIG_SND_SOC_RT5677_SPI))
++ return -ENXIO;
++
+ if (on && !activity) {
+ activity = true;
+
--- /dev/null
+From 033efa920a7f22a8caf7a38d851a2f451781bbf7 Mon Sep 17 00:00:00 2001
+From: Dmitry Tunin <hanipouspilot@gmail.com>
+Date: Sun, 18 Jan 2015 00:16:51 +0300
+Subject: Bluetooth: ath3k: Add support of AR3012 bluetooth 13d3:3423 device
+
+From: Dmitry Tunin <hanipouspilot@gmail.com>
+
+commit 033efa920a7f22a8caf7a38d851a2f451781bbf7 upstream.
+
+Add support of 13d3:3423 device.
+
+BugLink: https://bugs.launchpad.net/bugs/1411193
+
+T: Bus=01 Lev=02 Prnt=03 Port=00 Cnt=01 Dev#= 5 Spd=12 MxCh= 0
+D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
+P: Vendor=13d3 ProdID=3423 Rev= 0.01
+C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
+A: FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01
+I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
+E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
+E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
+E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
+I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
+E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
+E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
+I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
+E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
+E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
+I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
+E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
+E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
+I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
+E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
+E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
+I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
+E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
+E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
+I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
+E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
+E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
+
+Signed-off-by: Dmitry Tunin <hanipouspilot@gmail.com>
+Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/bluetooth/ath3k.c | 2 ++
+ drivers/bluetooth/btusb.c | 1 +
+ 2 files changed, 3 insertions(+)
+
+--- a/drivers/bluetooth/ath3k.c
++++ b/drivers/bluetooth/ath3k.c
+@@ -108,6 +108,7 @@ static const struct usb_device_id ath3k_
+ { USB_DEVICE(0x13d3, 0x3393) },
+ { USB_DEVICE(0x13d3, 0x3402) },
+ { USB_DEVICE(0x13d3, 0x3408) },
++ { USB_DEVICE(0x13d3, 0x3423) },
+ { USB_DEVICE(0x13d3, 0x3432) },
+
+ /* Atheros AR5BBU12 with sflash firmware */
+@@ -162,6 +163,7 @@ static const struct usb_device_id ath3k_
+ { USB_DEVICE(0x13d3, 0x3393), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x13d3, 0x3402), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x13d3, 0x3408), .driver_info = BTUSB_ATH3012 },
++ { USB_DEVICE(0x13d3, 0x3423), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x13d3, 0x3432), .driver_info = BTUSB_ATH3012 },
+
+ /* Atheros AR5BBU22 with sflash firmware */
+--- a/drivers/bluetooth/btusb.c
++++ b/drivers/bluetooth/btusb.c
+@@ -188,6 +188,7 @@ static const struct usb_device_id blackl
+ { USB_DEVICE(0x13d3, 0x3393), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x13d3, 0x3402), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x13d3, 0x3408), .driver_info = BTUSB_ATH3012 },
++ { USB_DEVICE(0x13d3, 0x3423), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x13d3, 0x3432), .driver_info = BTUSB_ATH3012 },
+
+ /* Atheros AR5BBU12 with sflash firmware */
--- /dev/null
+From c561a5753dd631920c4459a067d22679b3d110d6 Mon Sep 17 00:00:00 2001
+From: Adam Lee <adam.lee@canonical.com>
+Date: Wed, 28 Jan 2015 15:30:27 -0500
+Subject: Bluetooth: ath3k: workaround the compatibility issue with xHCI controller
+
+From: Adam Lee <adam.lee@canonical.com>
+
+commit c561a5753dd631920c4459a067d22679b3d110d6 upstream.
+
+BugLink: https://bugs.launchpad.net/bugs/1400215
+
+ath3k devices fail to load firmwares on xHCI buses, but work well on
+EHCI, this might be a compatibility issue between xHCI and ath3k chips.
+As my testing result, those chips will work on xHCI buses again with
+this patch.
+
+This workaround is from Qualcomm, they also did some workarounds in
+Windows driver.
+
+Signed-off-by: Adam Lee <adam.lee@canonical.com>
+Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/bluetooth/ath3k.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+--- a/drivers/bluetooth/ath3k.c
++++ b/drivers/bluetooth/ath3k.c
+@@ -174,6 +174,8 @@ static const struct usb_device_id ath3k_
+ #define USB_REQ_DFU_DNLOAD 1
+ #define BULK_SIZE 4096
+ #define FW_HDR_SIZE 20
++#define TIMEGAP_USEC_MIN 50
++#define TIMEGAP_USEC_MAX 100
+
+ static int ath3k_load_firmware(struct usb_device *udev,
+ const struct firmware *firmware)
+@@ -205,6 +207,9 @@ static int ath3k_load_firmware(struct us
+ pipe = usb_sndbulkpipe(udev, 0x02);
+
+ while (count) {
++ /* workaround the compatibility issue with xHCI controller*/
++ usleep_range(TIMEGAP_USEC_MIN, TIMEGAP_USEC_MAX);
++
+ size = min_t(uint, count, BULK_SIZE);
+ memcpy(send_buf, firmware->data + sent, size);
+
+@@ -302,6 +307,9 @@ static int ath3k_load_fwfile(struct usb_
+ pipe = usb_sndbulkpipe(udev, 0x02);
+
+ while (count) {
++ /* workaround the compatibility issue with xHCI controller*/
++ usleep_range(TIMEGAP_USEC_MIN, TIMEGAP_USEC_MAX);
++
+ size = min_t(uint, count, BULK_SIZE);
+ memcpy(send_buf, firmware->data + sent, size);
+
--- /dev/null
+From 9a5abdaaf9d2e80e157c7a756f9d9fd933dee48e Mon Sep 17 00:00:00 2001
+From: Rick Dunn <rick@rickdunn.com>
+Date: Sat, 17 Jan 2015 05:29:12 +0100
+Subject: Bluetooth: btusb: Add Broadcom patchram support for ASUSTek devices
+
+From: Rick Dunn <rick@rickdunn.com>
+
+commit 9a5abdaaf9d2e80e157c7a756f9d9fd933dee48e upstream.
+
+T: Bus=03 Lev=01 Prnt=01 Port=06 Cnt=02 Dev#= 3 Spd=12 MxCh= 0
+D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
+P: Vendor=0b05 ProdID=17cf Rev= 1.12
+S: Manufacturer=Broadcom Corp
+S: Product=BCM20702A0
+S: SerialNumber=54271E3298CD
+C:* #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr= 0mA
+I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
+E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
+E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
+E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
+I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
+E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
+E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
+I: If#= 1 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
+E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
+E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
+I: If#= 1 Alt= 2 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
+E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
+E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
+I: If#= 1 Alt= 3 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
+E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
+E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
+I: If#= 1 Alt= 4 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
+E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
+E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
+I: If#= 1 Alt= 5 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
+E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
+E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
+I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
+E: Ad=84(I) Atr=02(Bulk) MxPS= 32 Ivl=0ms
+E: Ad=04(O) Atr=02(Bulk) MxPS= 32 Ivl=0ms
+I:* If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)
+
+Firmware is extracted from the latest Broadcom BCM4352 Windows driver
+by extracting the zip and searching the .hex file names for '17cf'.
+
+The hex file must then be converted to hcd format using the hex2hcd
+utility and then moved to /lib/firmware/brcm/.
+
+Signed-off-by: Rick Dunn <rick@rickdunn.com>
+Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/bluetooth/btusb.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/bluetooth/btusb.c
++++ b/drivers/bluetooth/btusb.c
+@@ -118,7 +118,8 @@ static const struct usb_device_id btusb_
+ .driver_info = BTUSB_BCM_PATCHRAM },
+
+ /* ASUSTek Computer - Broadcom based */
+- { USB_VENDOR_AND_INTERFACE_INFO(0x0b05, 0xff, 0x01, 0x01) },
++ { USB_VENDOR_AND_INTERFACE_INFO(0x0b05, 0xff, 0x01, 0x01),
++ .driver_info = BTUSB_BCM_PATCHRAM },
+
+ /* Belkin F8065bf - Broadcom based */
+ { USB_VENDOR_AND_INTERFACE_INFO(0x050d, 0xff, 0x01, 0x01) },
--- /dev/null
+From d049f4e513e861167361b06c7ca85f9e872c8cde Mon Sep 17 00:00:00 2001
+From: Marcel Holtmann <marcel@holtmann.org>
+Date: Mon, 26 Jan 2015 20:35:32 -0800
+Subject: Bluetooth: btusb: Add support for Dynex/Insignia USB dongles
+
+From: Marcel Holtmann <marcel@holtmann.org>
+
+commit d049f4e513e861167361b06c7ca85f9e872c8cde upstream.
+
+The Dynex/Insignia USB dongles are Broadcom BCM20702B0 based and require
+firmware update before operation.
+
+T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0
+D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
+P: Vendor=19ff ProdID=0239 Rev= 1.12
+S: Manufacturer=Broadcom Corp
+S: Product=BCM20702A0
+C:* #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr= 0mA
+I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
+E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
+E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
+E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
+I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
+E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
+E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
+I: If#= 1 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
+E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
+E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
+I: If#= 1 Alt= 2 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
+E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
+E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
+I: If#= 1 Alt= 3 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
+E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
+E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
+I: If#= 1 Alt= 4 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
+E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
+E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
+I: If#= 1 Alt= 5 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
+E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
+E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
+I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
+E: Ad=84(I) Atr=02(Bulk) MxPS= 32 Ivl=0ms
+E: Ad=04(O) Atr=02(Bulk) MxPS= 32 Ivl=0ms
+I:* If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)
+
+Since this is an unsual USB vendor ID (0x19ff), these dongles are added
+via USB_DEVICE macro and not USB_VENDOR_AND_INTERFACE_INFO as done for
+mainstream Broadcom based dongles.
+
+The latest known working firmware is BCM20702B0_002.001.014.0527.0557.hex
+which needs to be converted using hex2hcd utility and then installed
+as /lib/firmware/brcm/BCM20702A0-19ff-0239.hcd to make this device fully
+operational.
+
+Bluetooth: hci0: BCM: patching hci_ver=06 hci_rev=2000 lmp_ver=06 lmp_subver=410e
+Bluetooth: hci0: BCM: firmware hci_ver=06 hci_rev=222d lmp_ver=06 lmp_subver=410e
+
+With this firmware the device reports support for connectionless slave
+broadcast (master and slave) feature used by 3D Glasses and TVs.
+
+ < HCI Command: Read Local Extended Features (0x04|0x0004) plen 1
+ Page: 2
+ > HCI Event: Command Complete (0x0e) plen 14
+ Read Local Extended Features (0x04|0x0004) ncmd 1
+ Status: Success (0x00)
+ Page: 2/2
+ Features: 0x0f 0x00 0x00 0x00 0x00 0x00 0x00 0x00
+ Connectionless Slave Broadcast - Master
+ Connectionless Slave Broadcast - Slave
+ Synchronization Train
+ Synchronization Scan
+
+However there are some flaws with this feature. The Set Event Mask Page 2
+command is actually not supported and with that all connectionless slave
+broadcast events are always enabled.
+
+ < HCI Command: Set Event Mask Page 2 (0x03|0x0063) plen 8
+ Mask: 0x00000000000f0000
+ Synchronization Train Received
+ Connectionless Slave Broadcast Receive
+ Connectionless Slave Broadcast Timeout
+ Truncated Page Complete
+ > HCI Event: Command Complete (0x0e) plen 4
+ Set Event Mask Page 2 (0x03|0x0063) ncmd 1
+ Status: Unknown HCI Command (0x01)
+
+In addition the Synchronization Train Received event is actually broken
+on this controller. It mixes up the order of parameters. According to the
+Bluetooth Core specification the fields are like this:
+
+ struct hci_ev_sync_train_received {
+ __u8 status;
+ bdaddr_t bdaddr;
+ __le32 offset;
+ __u8 map[10];
+ __u8 lt_addr;
+ __le32 instant;
+ __le16 interval;
+ __u8 service_data;
+ } __packed;
+
+This controller however sends the service_data as 5th parameter instead
+of having it as last parameter.
+
+ struct hci_ev_sync_train_received {
+ __u8 status;
+ bdaddr_t bdaddr;
+ __le32 offset;
+ __u8 map[10];
+ __u8 service_data;
+ __u8 lt_addr;
+ __le32 instant;
+ __le16 interval;
+ } __packed;
+
+So anybody trying to use this hardware for utilizing connectionless slave
+broadcast receivers (aka 3D Glasses), be warned about this shortcoming.
+
+Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
+Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/bluetooth/btusb.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/bluetooth/btusb.c
++++ b/drivers/bluetooth/btusb.c
+@@ -109,6 +109,9 @@ static const struct usb_device_id btusb_
+ { USB_DEVICE(0x13d3, 0x3404),
+ .driver_info = BTUSB_BCM_PATCHRAM },
+
++ /* Broadcom BCM20702B0 (Dynex/Insignia) */
++ { USB_DEVICE(0x19ff, 0x0239), .driver_info = BTUSB_BCM_PATCHRAM },
++
+ /* Foxconn - Hon Hai */
+ { USB_VENDOR_AND_INTERFACE_INFO(0x0489, 0xff, 0x01, 0x01),
+ .driver_info = BTUSB_BCM_PATCHRAM },
--- /dev/null
+From 8f0c304c693c5a9759ed6ae50d07d4590dad5ae7 Mon Sep 17 00:00:00 2001
+From: Matej Dubovy <matej.dubovy@gmail.com>
+Date: Mon, 2 Feb 2015 18:50:14 +0100
+Subject: Bluetooth: btusb: Add support for Lite-On (04ca) Broadcom based, BCM43142
+
+From: Matej Dubovy <matej.dubovy@gmail.com>
+
+commit 8f0c304c693c5a9759ed6ae50d07d4590dad5ae7 upstream.
+
+Please add support for sub BT chip on the combo card
+Broadcom 43142A0 (in Lenovo E145), 04ca:2007
+
+/sys/kernel/debug/usb/devices
+
+T: Bus=05 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#= 3 Spd=12 MxCh= 0
+D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
+P: Vendor=04ca ProdID=2007 Rev= 1.12
+S: Manufacturer=Broadcom Corp
+S: Product=BCM43142A0
+S: SerialNumber=28E347EC73BD
+C:* #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr= 0mA
+I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
+E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
+E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
+E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
+I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
+E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
+E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
+I: If#= 1 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
+E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
+E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
+I: If#= 1 Alt= 2 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
+E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
+E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
+I: If#= 1 Alt= 3 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
+E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
+E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
+I: If#= 1 Alt= 4 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
+E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
+E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
+I: If#= 1 Alt= 5 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
+E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
+E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
+I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
+E: Ad=84(I) Atr=02(Bulk) MxPS= 32 Ivl=0ms
+E: Ad=04(O) Atr=02(Bulk) MxPS= 32 Ivl=0ms
+I:* If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)
+
+Firmware for 04ca:2007 can be extracted from the latest Lenovo E145
+Bluetooth driver for Windows (driver is however described as BCM20702
+but contains also firwmare for BCM43142).
+Search for BCM43142A0_001.001.011.0122.0153.hex within hex files, then
+it must be converted using hex2hcd utility. Rename file to
+BCM43142A0-04ca-2007.hcd, then move to /lib/firmware/brcm/.
+
+Signed-off-by: Matej Dubovy <matej.dubovy@gmail.com>
+Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/bluetooth/btusb.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/drivers/bluetooth/btusb.c
++++ b/drivers/bluetooth/btusb.c
+@@ -116,6 +116,10 @@ static const struct usb_device_id btusb_
+ { USB_VENDOR_AND_INTERFACE_INFO(0x0489, 0xff, 0x01, 0x01),
+ .driver_info = BTUSB_BCM_PATCHRAM },
+
++ /* Lite-On Technology - Broadcom based */
++ { USB_VENDOR_AND_INTERFACE_INFO(0x04ca, 0xff, 0x01, 0x01),
++ .driver_info = BTUSB_BCM_PATCHRAM },
++
+ /* Broadcom devices with vendor specific id */
+ { USB_VENDOR_AND_INTERFACE_INFO(0x0a5c, 0xff, 0x01, 0x01),
+ .driver_info = BTUSB_BCM_PATCHRAM },
--- /dev/null
+From 91200e9f3e76af2652952e73ce5d9913f1c987c6 Mon Sep 17 00:00:00 2001
+From: Szymon Janc <szymon.janc@tieto.com>
+Date: Thu, 22 Jan 2015 16:57:05 +0100
+Subject: Bluetooth: Fix reporting invalid RSSI for LE devices
+
+From: Szymon Janc <szymon.janc@tieto.com>
+
+commit 91200e9f3e76af2652952e73ce5d9913f1c987c6 upstream.
+
+Start Discovery was reporting 0 RSSI for invalid RSSI only for
+BR/EDR devices. LE devices were reported with RSSI 127.
+
+Signed-off-by: Szymon Janc <szymon.janc@tieto.com>
+Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/bluetooth/mgmt.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/net/bluetooth/mgmt.c
++++ b/net/bluetooth/mgmt.c
+@@ -7066,7 +7066,8 @@ void mgmt_device_found(struct hci_dev *h
+ * However when using service discovery, the value 127 will be
+ * returned when the RSSI is not available.
+ */
+- if (rssi == HCI_RSSI_INVALID && !hdev->discovery.report_invalid_rssi)
++ if (rssi == HCI_RSSI_INVALID && !hdev->discovery.report_invalid_rssi &&
++ link_type == ACL_LINK)
+ rssi = 0;
+
+ bacpy(&ev->addr.bdaddr, bdaddr);
--- /dev/null
+From e12af489b91d47a806f4e96e4edc20df612482e7 Mon Sep 17 00:00:00 2001
+From: Johan Hedberg <johan.hedberg@intel.com>
+Date: Wed, 14 Jan 2015 20:51:37 +0200
+Subject: Bluetooth: Fix valid Identity Address check
+
+From: Johan Hedberg <johan.hedberg@intel.com>
+
+commit e12af489b91d47a806f4e96e4edc20df612482e7 upstream.
+
+According to the Bluetooth core specification valid identity addresses
+are either Public Device Addresses or Static Random Addresses. IRKs
+received with any other type of address should be discarded since we
+cannot assume to know the permanent identity of the peer device.
+
+This patch fixes a missing check for the Identity Address when receiving
+the Identity Address Information SMP PDU.
+
+Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
+Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/bluetooth/smp.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/net/bluetooth/smp.c
++++ b/net/bluetooth/smp.c
+@@ -2303,8 +2303,12 @@ static int smp_cmd_ident_addr_info(struc
+ * implementations are not known of and in order to not over
+ * complicate our implementation, simply pretend that we never
+ * received an IRK for such a device.
++ *
++ * The Identity Address must also be a Static Random or Public
++ * Address, which hci_is_identity_address() checks for.
+ */
+- if (!bacmp(&info->bdaddr, BDADDR_ANY)) {
++ if (!bacmp(&info->bdaddr, BDADDR_ANY) ||
++ !hci_is_identity_address(&info->bdaddr, info->addr_type)) {
+ BT_ERR("Ignoring IRK with no identity address");
+ goto distribute;
+ }
--- /dev/null
+From 6ee8e25fc3e916193bce4ebb43d5439e1e2144ab Mon Sep 17 00:00:00 2001
+From: Jan Kara <jack@suse.cz>
+Date: Tue, 10 Feb 2015 14:08:32 -0800
+Subject: fsnotify: fix handling of renames in audit
+
+From: Jan Kara <jack@suse.cz>
+
+commit 6ee8e25fc3e916193bce4ebb43d5439e1e2144ab upstream.
+
+Commit e9fd702a58c4 ("audit: convert audit watches to use fsnotify
+instead of inotify") broke handling of renames in audit. Audit code
+wants to update inode number of an inode corresponding to watched name
+in a directory. When something gets renamed into a directory to a
+watched name, inotify previously passed moved inode to audit code
+however new fsnotify code passes directory inode where the change
+happened. That confuses audit and it starts watching parent directory
+instead of a file in a directory.
+
+This can be observed for example by doing:
+
+ cd /tmp
+ touch foo bar
+ auditctl -w /tmp/foo
+ touch foo
+ mv bar foo
+ touch foo
+
+In audit log we see events like:
+
+ type=CONFIG_CHANGE msg=audit(1423563584.155:90): auid=1000 ses=2 op="updated rules" path="/tmp/foo" key=(null) list=4 res=1
+ ...
+ type=PATH msg=audit(1423563584.155:91): item=2 name="bar" inode=1046884 dev=08:0 2 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=DELETE
+ type=PATH msg=audit(1423563584.155:91): item=3 name="foo" inode=1046842 dev=08:0 2 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=DELETE
+ type=PATH msg=audit(1423563584.155:91): item=4 name="foo" inode=1046884 dev=08:0 2 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=CREATE
+ ...
+
+and that's it - we see event for the first touch after creating the
+audit rule, we see events for rename but we don't see any event for the
+last touch. However we start seeing events for unrelated stuff
+happening in /tmp.
+
+Fix the problem by passing moved inode as data in the FS_MOVED_FROM and
+FS_MOVED_TO events instead of the directory where the change happens.
+This doesn't introduce any new problems because noone besides
+audit_watch.c cares about the passed value:
+
+ fs/notify/fanotify/fanotify.c cares only about FSNOTIFY_EVENT_PATH events.
+ fs/notify/dnotify/dnotify.c doesn't care about passed 'data' value at all.
+ fs/notify/inotify/inotify_fsnotify.c uses 'data' only for FSNOTIFY_EVENT_PATH.
+ kernel/audit_tree.c doesn't care about passed 'data' at all.
+ kernel/audit_watch.c expects moved inode as 'data'.
+
+Fixes: e9fd702a58c49db ("audit: convert audit watches to use fsnotify instead of inotify")
+Signed-off-by: Jan Kara <jack@suse.cz>
+Cc: Paul Moore <paul@paul-moore.com>
+Cc: Eric Paris <eparis@redhat.com>
+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>
+
+---
+ include/linux/fsnotify.h | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/include/linux/fsnotify.h
++++ b/include/linux/fsnotify.h
+@@ -101,8 +101,10 @@ static inline void fsnotify_move(struct
+ new_dir_mask |= FS_ISDIR;
+ }
+
+- fsnotify(old_dir, old_dir_mask, old_dir, FSNOTIFY_EVENT_INODE, old_name, fs_cookie);
+- fsnotify(new_dir, new_dir_mask, new_dir, FSNOTIFY_EVENT_INODE, new_name, fs_cookie);
++ fsnotify(old_dir, old_dir_mask, source, FSNOTIFY_EVENT_INODE, old_name,
++ fs_cookie);
++ fsnotify(new_dir, new_dir_mask, source, FSNOTIFY_EVENT_INODE, new_name,
++ fs_cookie);
+
+ if (target)
+ fsnotify_link_count(target);
--- /dev/null
+From 6d00f37e49d95e640a3937a4a1ae07dbe92a10cb Mon Sep 17 00:00:00 2001
+From: Seth Forshee <seth.forshee@canonical.com>
+Date: Fri, 20 Feb 2015 11:45:11 -0600
+Subject: HID: i2c-hid: Limit reads to wMaxInputLength bytes for input events
+
+From: Seth Forshee <seth.forshee@canonical.com>
+
+commit 6d00f37e49d95e640a3937a4a1ae07dbe92a10cb upstream.
+
+d1c7e29e8d27 (HID: i2c-hid: prevent buffer overflow in early IRQ)
+changed hid_get_input() to read ihid->bufsize bytes, which can be
+more than wMaxInputLength. This is the case with the Dell XPS 13
+9343, and it is causing events to be missed. In some cases the
+missed events are releases, which can cause the cursor to jump or
+freeze, among other problems. Limit the number of bytes read to
+min(wMaxInputLength, ihid->bufsize) to prevent such problems.
+
+Fixes: d1c7e29e8d27 "HID: i2c-hid: prevent buffer overflow in early IRQ"
+Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
+Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
+Signed-off-by: Jiri Kosina <jkosina@suse.cz>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/hid/i2c-hid/i2c-hid.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/drivers/hid/i2c-hid/i2c-hid.c
++++ b/drivers/hid/i2c-hid/i2c-hid.c
+@@ -370,7 +370,10 @@ static int i2c_hid_hwreset(struct i2c_cl
+ static void i2c_hid_get_input(struct i2c_hid *ihid)
+ {
+ int ret, ret_size;
+- int size = ihid->bufsize;
++ int size = le16_to_cpu(ihid->hdesc.wMaxInputLength);
++
++ if (size > ihid->bufsize)
++ size = ihid->bufsize;
+
+ ret = i2c_master_recv(ihid->client, ihid->inbuf, size);
+ if (ret != size) {
--- /dev/null
+From 5523d11cc46393a1e61b7ef4a0b2d4e7ed9521e4 Mon Sep 17 00:00:00 2001
+From: Luciano Coelho <luciano.coelho@intel.com>
+Date: Thu, 29 Jan 2015 12:48:20 +0200
+Subject: iwlwifi: mvm: always use mac color zero
+
+From: Luciano Coelho <luciano.coelho@intel.com>
+
+commit 5523d11cc46393a1e61b7ef4a0b2d4e7ed9521e4 upstream.
+
+We don't really need to use different mac colors when adding mac
+contexts, because they're not used anywhere. In fact, the firmware
+doesn't accept 255 as a valid color, so we get into a SYSASSERT 0x3401
+when we reach that.
+
+Remove the color increment to use always zero and avoid reaching 255.
+
+Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
+Reviewed-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/wireless/iwlwifi/mvm/mac80211.c | 3 ---
+ 1 file changed, 3 deletions(-)
+
+--- a/drivers/net/wireless/iwlwifi/mvm/mac80211.c
++++ b/drivers/net/wireless/iwlwifi/mvm/mac80211.c
+@@ -707,9 +707,6 @@ static void iwl_mvm_cleanup_iterator(voi
+ mvmvif->uploaded = false;
+ mvmvif->ap_sta_id = IWL_MVM_STATION_COUNT;
+
+- /* does this make sense at all? */
+- mvmvif->color++;
+-
+ spin_lock_bh(&mvm->time_event_lock);
+ iwl_mvm_te_clear_data(mvm, &mvmvif->time_event_data);
+ spin_unlock_bh(&mvm->time_event_lock);
--- /dev/null
+From fd66fc1cafd72ddf27dbec3a5e29e99839d1bc84 Mon Sep 17 00:00:00 2001
+From: Luciano Coelho <luciano.coelho@intel.com>
+Date: Tue, 27 Jan 2015 15:06:57 +0200
+Subject: iwlwifi: mvm: fix failure path when power_update fails in add_interface
+
+From: Luciano Coelho <luciano.coelho@intel.com>
+
+commit fd66fc1cafd72ddf27dbec3a5e29e99839d1bc84 upstream.
+
+When iwl_mvm_power_update_mac() is called, we have already added the
+mac context, so if this call fails we should remove the mac.
+
+Fixes: commit e5e7aa8e2561 ('iwlwifi: mvm: refactor power code')
+Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
+Reviewed-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/wireless/iwlwifi/mvm/mac80211.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/net/wireless/iwlwifi/mvm/mac80211.c
++++ b/drivers/net/wireless/iwlwifi/mvm/mac80211.c
+@@ -1146,7 +1146,7 @@ static int iwl_mvm_mac_add_interface(str
+
+ ret = iwl_mvm_power_update_mac(mvm);
+ if (ret)
+- goto out_release;
++ goto out_remove_mac;
+
+ /* beacon filtering */
+ ret = iwl_mvm_disable_beacon_filter(mvm, vif, 0);
--- /dev/null
+From 2cee4762c528a9bd2cdff793197bf591a2196c11 Mon Sep 17 00:00:00 2001
+From: Eyal Shapira <eyal@wizery.com>
+Date: Fri, 16 Jan 2015 11:09:30 +0200
+Subject: iwlwifi: mvm: validate tid and sta_id in ba_notif
+
+From: Eyal Shapira <eyal@wizery.com>
+
+commit 2cee4762c528a9bd2cdff793197bf591a2196c11 upstream.
+
+These are coming from the FW and are used to access arrays.
+Bad values can cause an out of bounds access so discard
+such ba_notifs and warn.
+
+Signed-off-by: Eyal Shapira <eyalx.shapira@intel.com>
+Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/wireless/iwlwifi/mvm/tx.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/drivers/net/wireless/iwlwifi/mvm/tx.c
++++ b/drivers/net/wireless/iwlwifi/mvm/tx.c
+@@ -930,6 +930,11 @@ int iwl_mvm_rx_ba_notif(struct iwl_mvm *
+ sta_id = ba_notif->sta_id;
+ tid = ba_notif->tid;
+
++ if (WARN_ONCE(sta_id >= IWL_MVM_STATION_COUNT ||
++ tid >= IWL_MAX_TID_COUNT,
++ "sta_id %d tid %d", sta_id, tid))
++ return 0;
++
+ rcu_read_lock();
+
+ sta = rcu_dereference(mvm->fw_id_to_mac_id[sta_id]);
--- /dev/null
+From cd8f438405032ac8ff88bd8f2eca5e0c0063b14b Mon Sep 17 00:00:00 2001
+From: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
+Date: Thu, 29 Jan 2015 21:34:00 +0200
+Subject: iwlwifi: pcie: disable the SCD_BASE_ADDR when we resume from WoWLAN
+
+From: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
+
+commit cd8f438405032ac8ff88bd8f2eca5e0c0063b14b upstream.
+
+The base address of the scheduler in the device's memory
+(SRAM) comes from two different sources. The periphery
+register and the alive notification from the firmware.
+We have a check in iwl_pcie_tx_start that ensures that
+they are the same.
+When we resume from WoWLAN, the firmware may have crashed
+for whatever reason. In that case, the whole device may be
+reset which means that the periphery register will hold a
+meaningless value. When we come to compare
+trans_pcie->scd_base_addr (which really holds the value we
+had when we loaded the WoWLAN firmware upon suspend) and
+the current value of the register, we don't see a match
+unsurprisingly.
+Trick the check to avoid a loud yet harmless WARN.
+Note that when the WoWLAN has crashed, we will see that
+in iwl_trans_pcie_d3_resume which will let the op_mode
+know. Once the op_mode is informed that the WowLAN firmware
+has crashed, it can't do much besides resetting the whole
+device.
+
+Reviewed-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/wireless/iwlwifi/pcie/tx.c | 7 ++++++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+--- a/drivers/net/wireless/iwlwifi/pcie/tx.c
++++ b/drivers/net/wireless/iwlwifi/pcie/tx.c
+@@ -722,7 +722,12 @@ void iwl_trans_pcie_tx_reset(struct iwl_
+ iwl_write_direct32(trans, FH_KW_MEM_ADDR_REG,
+ trans_pcie->kw.dma >> 4);
+
+- iwl_pcie_tx_start(trans, trans_pcie->scd_base_addr);
++ /*
++ * Send 0 as the scd_base_addr since the device may have be reset
++ * while we were in WoWLAN in which case SCD_SRAM_BASE_ADDR will
++ * contain garbage.
++ */
++ iwl_pcie_tx_start(trans, 0);
+ }
+
+ /*
--- /dev/null
+From 28423ad283d5348793b0c45cc9b1af058e776fd6 Mon Sep 17 00:00:00 2001
+From: Calvin Owens <calvinowens@fb.com>
+Date: Tue, 13 Jan 2015 13:16:18 -0800
+Subject: ksoftirqd: Enable IRQs and call cond_resched() before poking RCU
+
+From: Calvin Owens <calvinowens@fb.com>
+
+commit 28423ad283d5348793b0c45cc9b1af058e776fd6 upstream.
+
+While debugging an issue with excessive softirq usage, I encountered the
+following note in commit 3e339b5dae24a706 ("softirq: Use hotplug thread
+infrastructure"):
+
+ [ paulmck: Call rcu_note_context_switch() with interrupts enabled. ]
+
+...but despite this note, the patch still calls RCU with IRQs disabled.
+
+This seemingly innocuous change caused a significant regression in softirq
+CPU usage on the sending side of a large TCP transfer (~1 GB/s): when
+introducing 0.01% packet loss, the softirq usage would jump to around 25%,
+spiking as high as 50%. Before the change, the usage would never exceed 5%.
+
+Moving the call to rcu_note_context_switch() after the cond_sched() call,
+as it was originally before the hotplug patch, completely eliminated this
+problem.
+
+Signed-off-by: Calvin Owens <calvinowens@fb.com>
+Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/softirq.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/kernel/softirq.c
++++ b/kernel/softirq.c
+@@ -656,9 +656,13 @@ static void run_ksoftirqd(unsigned int c
+ * in the task stack here.
+ */
+ __do_softirq();
+- rcu_note_context_switch();
+ local_irq_enable();
+ cond_resched();
++
++ preempt_disable();
++ rcu_note_context_switch();
++ preempt_enable();
++
+ return;
+ }
+ local_irq_enable();
--- /dev/null
+From 16b036af31e1456cb69243a5a0c9ef801ecd1f17 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Michel=20D=C3=A4nzer?= <michel.daenzer@amd.com>
+Date: Mon, 19 Jan 2015 17:53:20 +0900
+Subject: PCI: Fix infinite loop with ROM image of size 0
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: =?UTF-8?q?Michel=20D=C3=A4nzer?= <michel.daenzer@amd.com>
+
+commit 16b036af31e1456cb69243a5a0c9ef801ecd1f17 upstream.
+
+If the image size would ever read as 0, pci_get_rom_size() could keep
+processing the same image over and over again. Exit the loop if we ever
+read a length of zero.
+
+This fixes a soft lockup on boot when the radeon driver calls
+pci_get_rom_size() on an AMD Radeon R7 250X PCIe discrete graphics card.
+
+[bhelgaas: changelog, reference]
+Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1386973
+Reported-by: Federico <federicotg@gmail.com>
+Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/pci/rom.c | 7 ++++---
+ 1 file changed, 4 insertions(+), 3 deletions(-)
+
+--- a/drivers/pci/rom.c
++++ b/drivers/pci/rom.c
+@@ -71,6 +71,7 @@ size_t pci_get_rom_size(struct pci_dev *
+ {
+ void __iomem *image;
+ int last_image;
++ unsigned length;
+
+ image = rom;
+ do {
+@@ -93,9 +94,9 @@ size_t pci_get_rom_size(struct pci_dev *
+ if (readb(pds + 3) != 'R')
+ break;
+ last_image = readb(pds + 21) & 0x80;
+- /* this length is reliable */
+- image += readw(pds + 16) * 512;
+- } while (!last_image);
++ length = readw(pds + 16);
++ image += length * 512;
++ } while (length && !last_image);
+
+ /* never return a size larger than the PCI resource window */
+ /* there are known ROMs that get the size wrong */
--- /dev/null
+From 145b3fe579db66fbe999a2bc3fd5b63dffe9636d Mon Sep 17 00:00:00 2001
+From: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
+Date: Tue, 2 Dec 2014 17:35:04 +0100
+Subject: PCI: Generate uppercase hex for modalias var in uevent
+
+From: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
+
+commit 145b3fe579db66fbe999a2bc3fd5b63dffe9636d upstream.
+
+Some implementations of modprobe fail to load the driver for a PCI device
+automatically because the "interface" part of the modalias from the kernel
+is lowercase, and the modalias from file2alias is uppercase.
+
+The "interface" is the low-order byte of the Class Code, defined in PCI
+r3.0, Appendix D. Most interface types defined in the spec do not use
+alpha characters, so they won't be affected. For example, 00h, 01h, 10h,
+20h, etc. are unaffected.
+
+Print the "interface" byte of the Class Code in uppercase hex, as we
+already do for the Vendor ID, Device ID, Class, etc.
+
+Commit 89ec3dcf17fd ("PCI: Generate uppercase hex for modalias interface
+class") fixed only half of the problem. Some udev implementations rely on
+the uevent file and not the modalias file.
+
+Fixes: d1ded203adf1 ("PCI: add MODALIAS to hotplug event for pci devices")
+Fixes: 89ec3dcf17fd ("PCI: Generate uppercase hex for modalias interface class")
+Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/pci/pci-driver.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/pci/pci-driver.c
++++ b/drivers/pci/pci-driver.c
+@@ -1383,7 +1383,7 @@ static int pci_uevent(struct device *dev
+ if (add_uevent_var(env, "PCI_SLOT_NAME=%s", pci_name(pdev)))
+ return -ENOMEM;
+
+- if (add_uevent_var(env, "MODALIAS=pci:v%08Xd%08Xsv%08Xsd%08Xbc%02Xsc%02Xi%02x",
++ if (add_uevent_var(env, "MODALIAS=pci:v%08Xd%08Xsv%08Xsd%08Xbc%02Xsc%02Xi%02X",
+ pdev->vendor, pdev->device,
+ pdev->subsystem_vendor, pdev->subsystem_device,
+ (u8)(pdev->class >> 16), (u8)(pdev->class >> 8),
--- /dev/null
+From 19acc77a36970958a4a0e4daeb2c8cb2aab0ffd4 Mon Sep 17 00:00:00 2001
+From: George Spelvin <linux@horizon.com>
+Date: Sat, 7 Feb 2015 00:32:06 -0500
+Subject: random: Fix fast_mix() function
+
+From: George Spelvin <linux@horizon.com>
+
+commit 19acc77a36970958a4a0e4daeb2c8cb2aab0ffd4 upstream.
+
+There was a bad typo in commit 43759d4f429c ("random: use an improved
+fast_mix() function") and I didn't notice because it "looked right", so
+I saw what I expected to see when I reviewed it.
+
+Only months later did I look and notice it's not the Threefish-inspired
+mix function that I had designed and optimized.
+
+Mea Culpa. Each input bit still has a chance to affect each output bit,
+and the fast pool is spilled *long* before it fills, so it's not a total
+disaster, but it's definitely not the intended great improvement.
+
+I'm still working on finding better rotation constants. These are good
+enough, but since it's unrolled twice, it's possible to get better
+mixing for free by using eight different constants rather than repeating
+the same four.
+
+Signed-off-by: George Spelvin <linux@horizon.com>
+Cc: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/char/random.c | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+--- a/drivers/char/random.c
++++ b/drivers/char/random.c
+@@ -569,19 +569,19 @@ static void fast_mix(struct fast_pool *f
+ __u32 c = f->pool[2], d = f->pool[3];
+
+ a += b; c += d;
+- b = rol32(a, 6); d = rol32(c, 27);
++ b = rol32(b, 6); d = rol32(d, 27);
+ d ^= a; b ^= c;
+
+ a += b; c += d;
+- b = rol32(a, 16); d = rol32(c, 14);
++ b = rol32(b, 16); d = rol32(d, 14);
+ d ^= a; b ^= c;
+
+ a += b; c += d;
+- b = rol32(a, 6); d = rol32(c, 27);
++ b = rol32(b, 6); d = rol32(d, 27);
+ d ^= a; b ^= c;
+
+ a += b; c += d;
+- b = rol32(a, 16); d = rol32(c, 14);
++ b = rol32(b, 16); d = rol32(d, 14);
+ d ^= a; b ^= c;
+
+ f->pool[0] = a; f->pool[1] = b;
--- /dev/null
+From 23b133bdc452aa441fcb9b82cbf6dd05cfd342d0 Mon Sep 17 00:00:00 2001
+From: Jan Kara <jack@suse.cz>
+Date: Wed, 7 Jan 2015 13:49:08 +0100
+Subject: udf: Check length of extended attributes and allocation descriptors
+
+From: Jan Kara <jack@suse.cz>
+
+commit 23b133bdc452aa441fcb9b82cbf6dd05cfd342d0 upstream.
+
+Check length of extended attributes and allocation descriptors when
+loading inodes from disk. Otherwise corrupted filesystems could confuse
+the code and make the kernel oops.
+
+Reported-by: Carl Henrik Lunde <chlunde@ping.uio.no>
+Signed-off-by: Jan Kara <jack@suse.cz>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/udf/inode.c | 9 +++++++++
+ 1 file changed, 9 insertions(+)
+
+--- a/fs/udf/inode.c
++++ b/fs/udf/inode.c
+@@ -1489,6 +1489,15 @@ reread:
+ }
+ inode->i_generation = iinfo->i_unique;
+
++ /*
++ * Sanity check length of allocation descriptors and extended attrs to
++ * avoid integer overflows
++ */
++ if (iinfo->i_lenEAttr > bs || iinfo->i_lenAlloc > bs)
++ goto out;
++ /* Now do exact checks */
++ if (udf_file_entry_alloc_offset(inode) + iinfo->i_lenAlloc > bs)
++ goto out;
+ /* Sanity checks for files in ICB so that we don't get confused later */
+ if (iinfo->i_alloc_type == ICBTAG_FLAG_AD_IN_ICB) {
+ /*
--- /dev/null
+From 0d612fb570b71ea2e49554a770cff4c489018b2c Mon Sep 17 00:00:00 2001
+From: Dave Chinner <dchinner@redhat.com>
+Date: Thu, 22 Jan 2015 09:29:05 +1100
+Subject: xfs: ensure buffer types are set correctly
+
+From: Dave Chinner <dchinner@redhat.com>
+
+commit 0d612fb570b71ea2e49554a770cff4c489018b2c upstream.
+
+Jan Kara reported that log recovery was finding buffers with invalid
+types in them. This should not happen, and indicates a bug in the
+logging of buffers. To catch this, add asserts to the buffer
+formatting code to ensure that the buffer type is in range when the
+transaction is committed.
+
+We don't set a type on buffers being marked stale - they are not
+going to get replayed, the format item exists only for recovery to
+be able to prevent replay of the buffer, so the type does not
+matter. Hence that needs special casing here.
+
+Reported-by: Jan Kara <jack@suse.cz>
+Tested-by: Jan Kara <jack@suse.cz>
+Signed-off-by: Dave Chinner <dchinner@redhat.com>
+Reviewed-by: Brian Foster <bfoster@redhat.com>
+Signed-off-by: Dave Chinner <david@fromorbit.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/xfs/xfs_buf_item.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/fs/xfs/xfs_buf_item.c
++++ b/fs/xfs/xfs_buf_item.c
+@@ -319,6 +319,10 @@ xfs_buf_item_format(
+ ASSERT(atomic_read(&bip->bli_refcount) > 0);
+ ASSERT((bip->bli_flags & XFS_BLI_LOGGED) ||
+ (bip->bli_flags & XFS_BLI_STALE));
++ ASSERT((bip->bli_flags & XFS_BLI_STALE) ||
++ (xfs_blft_from_flags(&bip->__bli_format) > XFS_BLFT_UNKNOWN_BUF
++ && xfs_blft_from_flags(&bip->__bli_format) < XFS_BLFT_MAX_BUF));
++
+
+ /*
+ * If it is an inode buffer, transfer the in-memory state to the
--- /dev/null
+From f19b872b086711bb4b22c3a0f52f16aa920bcc61 Mon Sep 17 00:00:00 2001
+From: Dave Chinner <dchinner@redhat.com>
+Date: Thu, 22 Jan 2015 09:29:40 +1100
+Subject: xfs: inode unlink does not set AGI buffer type
+
+From: Dave Chinner <dchinner@redhat.com>
+
+commit f19b872b086711bb4b22c3a0f52f16aa920bcc61 upstream.
+
+This leads to log recovery throwing errors like:
+
+XFS (md0): Mounting V5 Filesystem
+XFS (md0): Starting recovery (logdev: internal)
+XFS (md0): Unknown buffer type 0!
+XFS (md0): _xfs_buf_ioapply: no ops on block 0xaea8802/0x1
+ffff8800ffc53800: 58 41 47 49 .....
+
+Which is the AGI buffer magic number.
+
+Ensure that we set the type appropriately in both unlink list
+addition and removal.
+
+Tested-by: Jan Kara <jack@suse.cz>
+Signed-off-by: Dave Chinner <dchinner@redhat.com>
+Reviewed-by: Brian Foster <bfoster@redhat.com>
+Signed-off-by: Dave Chinner <david@fromorbit.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/xfs/xfs_inode.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/fs/xfs/xfs_inode.c
++++ b/fs/xfs/xfs_inode.c
+@@ -1995,6 +1995,7 @@ xfs_iunlink(
+ agi->agi_unlinked[bucket_index] = cpu_to_be32(agino);
+ offset = offsetof(xfs_agi_t, agi_unlinked) +
+ (sizeof(xfs_agino_t) * bucket_index);
++ xfs_trans_buf_set_type(tp, agibp, XFS_BLFT_AGI_BUF);
+ xfs_trans_log_buf(tp, agibp, offset,
+ (offset + sizeof(xfs_agino_t) - 1));
+ return 0;
+@@ -2086,6 +2087,7 @@ xfs_iunlink_remove(
+ agi->agi_unlinked[bucket_index] = cpu_to_be32(next_agino);
+ offset = offsetof(xfs_agi_t, agi_unlinked) +
+ (sizeof(xfs_agino_t) * bucket_index);
++ xfs_trans_buf_set_type(tp, agibp, XFS_BLFT_AGI_BUF);
+ xfs_trans_log_buf(tp, agibp, offset,
+ (offset + sizeof(xfs_agino_t) - 1));
+ } else {
--- /dev/null
+From e9892d3cc853afdda2cc69e2576d9ddb5fafad71 Mon Sep 17 00:00:00 2001
+From: Dave Chinner <dchinner@redhat.com>
+Date: Tue, 10 Feb 2015 09:23:40 +1100
+Subject: xfs: only trace buffer items if they exist
+
+From: Dave Chinner <dchinner@redhat.com>
+
+commit e9892d3cc853afdda2cc69e2576d9ddb5fafad71 upstream.
+
+The commit 2d3d0c5 ("xfs: lobotomise xfs_trans_read_buf_map()") left
+a landmine in the tracing code: trace_xfs_trans_buf_read() is now
+call on all buffers that are read through this interface rather than
+just buffers in transactions. For buffers outside transaction
+context, bp->b_fspriv is null, and so the buf log item tracing
+functions cannot be called. This causes a NULL pointer dereference
+in the trace_xfs_trans_buf_read() function when tracing is turned
+on.
+
+Signed-off-by: Dave Chinner <dchinner@redhat.com>
+Reviewed-by: Brian Foster <bfoster@redhat.com>
+Signed-off-by: Dave Chinner <david@fromorbit.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/xfs/xfs_trans_buf.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/fs/xfs/xfs_trans_buf.c
++++ b/fs/xfs/xfs_trans_buf.c
+@@ -327,9 +327,10 @@ xfs_trans_read_buf_map(
+ return -EIO;
+ }
+
+- if (tp)
++ if (tp) {
+ _xfs_trans_bjoin(tp, bp, 1);
+- trace_xfs_trans_read_buf(bp->b_fspriv);
++ trace_xfs_trans_read_buf(bp->b_fspriv);
++ }
+ *bpp = bp;
+ return 0;
+
--- /dev/null
+From fe22d552b82d7cc7de1851233ae8bef579198637 Mon Sep 17 00:00:00 2001
+From: Dave Chinner <dchinner@redhat.com>
+Date: Thu, 22 Jan 2015 09:30:06 +1100
+Subject: xfs: set buf types when converting extent formats
+
+From: Dave Chinner <dchinner@redhat.com>
+
+commit fe22d552b82d7cc7de1851233ae8bef579198637 upstream.
+
+Conversion from local to extent format does not set the buffer type
+correctly on the new extent buffer when a symlink data is moved out
+of line.
+
+Fix the symlink code and leave a comment in the generic bmap code
+reminding us that the format-specific data copy needs to set the
+destination buffer type appropriately.
+
+Tested-by: Jan Kara <jack@suse.cz>
+Signed-off-by: Dave Chinner <dchinner@redhat.com>
+Reviewed-by: Brian Foster <bfoster@redhat.com>
+Signed-off-by: Dave Chinner <david@fromorbit.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/xfs/libxfs/xfs_bmap.c | 6 +++++-
+ fs/xfs/libxfs/xfs_symlink_remote.c | 2 ++
+ 2 files changed, 7 insertions(+), 1 deletion(-)
+
+--- a/fs/xfs/libxfs/xfs_bmap.c
++++ b/fs/xfs/libxfs/xfs_bmap.c
+@@ -973,7 +973,11 @@ xfs_bmap_local_to_extents(
+ *firstblock = args.fsbno;
+ bp = xfs_btree_get_bufl(args.mp, tp, args.fsbno, 0);
+
+- /* initialise the block and copy the data */
++ /*
++ * Initialise the block and copy the data
++ *
++ * Note: init_fn must set the buffer log item type correctly!
++ */
+ init_fn(tp, bp, ip, ifp);
+
+ /* account for the change in fork size and log everything */
+--- a/fs/xfs/libxfs/xfs_symlink_remote.c
++++ b/fs/xfs/libxfs/xfs_symlink_remote.c
+@@ -178,6 +178,8 @@ xfs_symlink_local_to_remote(
+ struct xfs_mount *mp = ip->i_mount;
+ char *buf;
+
++ xfs_trans_buf_set_type(tp, bp, XFS_BLFT_SYMLINK_BUF);
++
+ if (!xfs_sb_version_hascrc(&mp->m_sb)) {
+ bp->b_ops = NULL;
+ memcpy(bp->b_addr, ifp->if_u1.if_data, ifp->if_bytes);
--- /dev/null
+From 3443a3bca54588f43286b725d8648d33a38c86f1 Mon Sep 17 00:00:00 2001
+From: Dave Chinner <dchinner@redhat.com>
+Date: Thu, 22 Jan 2015 09:30:23 +1100
+Subject: xfs: set superblock buffer type correctly
+
+From: Dave Chinner <dchinner@redhat.com>
+
+commit 3443a3bca54588f43286b725d8648d33a38c86f1 upstream.
+
+When the superblock is modified in a transaction, the commonly
+modified fields are not actually copied to the superblock buffer to
+avoid the buffer lock becoming a serialisation point. However, there
+are some other operations that modify the superblock fields within
+the transaction that don't directly log to the superblock but rely
+on the changes to be applied during the transaction commit (to
+minimise the buffer lock hold time).
+
+When we do this, we fail to mark the buffer log item as being a
+superblock buffer and that can lead to the buffer not being marked
+with the corect type in the log and hence causing recovery issues.
+Fix it by setting the type correctly, similar to xfs_mod_sb()...
+
+Tested-by: Jan Kara <jack@suse.cz>
+Signed-off-by: Dave Chinner <dchinner@redhat.com>
+Reviewed-by: Brian Foster <bfoster@redhat.com>
+Signed-off-by: Dave Chinner <david@fromorbit.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/xfs/xfs_trans.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/fs/xfs/xfs_trans.c
++++ b/fs/xfs/xfs_trans.c
+@@ -472,6 +472,7 @@ xfs_trans_apply_sb_deltas(
+ whole = 1;
+ }
+
++ xfs_trans_buf_set_type(tp, bp, XFS_BLFT_SB_BUF);
+ if (whole)
+ /*
+ * Log the whole thing, the fields are noncontiguous.
projects / thirdparty / kernel / stable-queue.git / commitdiff
