--- /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
+@@ -157,6 +157,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)
+@@ -187,6 +189,9 @@ static int ath3k_load_firmware(struct us
+ count -= 20;
+
+ while (count) {
++ /* workaround the compatibility issue with xHCI controller*/
++ usleep_range(TIMEGAP_USEC_MIN, TIMEGAP_USEC_MAX);
++
+ size = min_t(uint, count, BULK_SIZE);
+ pipe = usb_sndbulkpipe(udev, 0x02);
+ memcpy(send_buf, firmware->data + sent, size);
+@@ -283,6 +288,9 @@ static int ath3k_load_fwfile(struct usb_
+ count -= size;
+
+ while (count) {
++ /* workaround the compatibility issue with xHCI controller*/
++ usleep_range(TIMEGAP_USEC_MIN, TIMEGAP_USEC_MAX);
++
+ size = min_t(uint, count, BULK_SIZE);
+ pipe = usb_sndbulkpipe(udev, 0x02);
+
--- /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
+@@ -107,6 +107,9 @@ static const struct usb_device_id btusb_
+ { USB_DEVICE(0x0489, 0xe042) },
+ { USB_DEVICE(0x413c, 0x8197) },
+
++ /* 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) },
+
--- /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
+@@ -356,7 +356,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
+@@ -410,9 +410,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
+@@ -597,7 +597,7 @@ static int iwl_mvm_mac_add_interface(str
+
+ ret = iwl_mvm_mac_ctxt_add(mvm, vif);
+ if (ret)
+- goto out_release;
++ goto out_remove_mac;
+
+ iwl_mvm_power_disable(mvm, vif);
+
--- /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
+@@ -835,6 +835,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
+@@ -729,7 +729,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 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
+@@ -69,6 +69,7 @@ size_t pci_get_rom_size(struct pci_dev *
+ {
+ void __iomem *image;
+ int last_image;
++ unsigned length;
+
+ image = rom;
+ do {
+@@ -91,9 +92,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
+@@ -1324,7 +1324,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 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
+@@ -1946,6 +1946,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;
+@@ -2037,6 +2038,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 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
+@@ -474,6 +474,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
