From 301dffb3f1589a069c5450120beade5e450fad04 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Sat, 28 Feb 2015 14:04:39 -0800 Subject: [PATCH] 3.10-stable patches added patches: bluetooth-ath3k-workaround-the-compatibility-issue-with-xhci-controller.patch bluetooth-btusb-add-support-for-dynex-insignia-usb-dongles.patch fsnotify-fix-handling-of-renames-in-audit.patch hid-i2c-hid-limit-reads-to-wmaxinputlength-bytes-for-input-events.patch iwlwifi-mvm-always-use-mac-color-zero.patch iwlwifi-mvm-fix-failure-path-when-power_update-fails-in-add_interface.patch iwlwifi-mvm-validate-tid-and-sta_id-in-ba_notif.patch iwlwifi-pcie-disable-the-scd_base_addr-when-we-resume-from-wowlan.patch pci-fix-infinite-loop-with-rom-image-of-size-0.patch pci-generate-uppercase-hex-for-modalias-var-in-uevent.patch xfs-ensure-buffer-types-are-set-correctly.patch xfs-inode-unlink-does-not-set-agi-buffer-type.patch xfs-set-superblock-buffer-type-correctly.patch --- ...atibility-issue-with-xhci-controller.patch | 58 ++++++++ ...pport-for-dynex-insignia-usb-dongles.patch | 138 ++++++++++++++++++ ...ify-fix-handling-of-renames-in-audit.patch | 79 ++++++++++ ...axinputlength-bytes-for-input-events.patch | 41 ++++++ ...wlwifi-mvm-always-use-mac-color-zero.patch | 37 +++++ ...-power_update-fails-in-add_interface.patch | 33 +++++ ...-validate-tid-and-sta_id-in-ba_notif.patch | 35 +++++ ...base_addr-when-we-resume-from-wowlan.patch | 53 +++++++ ...finite-loop-with-rom-image-of-size-0.patch | 54 +++++++ ...rcase-hex-for-modalias-var-in-uevent.patch | 47 ++++++ queue-3.10/series | 13 ++ ...nsure-buffer-types-are-set-correctly.patch | 44 ++++++ ...-unlink-does-not-set-agi-buffer-type.patch | 50 +++++++ ...set-superblock-buffer-type-correctly.patch | 42 ++++++ queue-3.14/series | 13 ++ queue-3.19/series | 27 ++++ 16 files changed, 764 insertions(+) create mode 100644 queue-3.10/bluetooth-ath3k-workaround-the-compatibility-issue-with-xhci-controller.patch create mode 100644 queue-3.10/bluetooth-btusb-add-support-for-dynex-insignia-usb-dongles.patch create mode 100644 queue-3.10/fsnotify-fix-handling-of-renames-in-audit.patch create mode 100644 queue-3.10/hid-i2c-hid-limit-reads-to-wmaxinputlength-bytes-for-input-events.patch create mode 100644 queue-3.10/iwlwifi-mvm-always-use-mac-color-zero.patch create mode 100644 queue-3.10/iwlwifi-mvm-fix-failure-path-when-power_update-fails-in-add_interface.patch create mode 100644 queue-3.10/iwlwifi-mvm-validate-tid-and-sta_id-in-ba_notif.patch create mode 100644 queue-3.10/iwlwifi-pcie-disable-the-scd_base_addr-when-we-resume-from-wowlan.patch create mode 100644 queue-3.10/pci-fix-infinite-loop-with-rom-image-of-size-0.patch create mode 100644 queue-3.10/pci-generate-uppercase-hex-for-modalias-var-in-uevent.patch create mode 100644 queue-3.10/series create mode 100644 queue-3.10/xfs-ensure-buffer-types-are-set-correctly.patch create mode 100644 queue-3.10/xfs-inode-unlink-does-not-set-agi-buffer-type.patch create mode 100644 queue-3.10/xfs-set-superblock-buffer-type-correctly.patch create mode 100644 queue-3.14/series diff --git a/queue-3.10/bluetooth-ath3k-workaround-the-compatibility-issue-with-xhci-controller.patch b/queue-3.10/bluetooth-ath3k-workaround-the-compatibility-issue-with-xhci-controller.patch new file mode 100644 index 00000000000..3a258b51a6d --- /dev/null +++ b/queue-3.10/bluetooth-ath3k-workaround-the-compatibility-issue-with-xhci-controller.patch @@ -0,0 +1,58 @@ +From c561a5753dd631920c4459a067d22679b3d110d6 Mon Sep 17 00:00:00 2001 +From: Adam Lee +Date: Wed, 28 Jan 2015 15:30:27 -0500 +Subject: Bluetooth: ath3k: workaround the compatibility issue with xHCI controller + +From: Adam Lee + +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 +Signed-off-by: Marcel Holtmann +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/bluetooth/ath3k.c | 8 ++++++++ + 1 file changed, 8 insertions(+) + +--- a/drivers/bluetooth/ath3k.c ++++ b/drivers/bluetooth/ath3k.c +@@ -151,6 +151,8 @@ static struct usb_device_id ath3k_blist_ + #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) +@@ -181,6 +183,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); +@@ -277,6 +282,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); + diff --git a/queue-3.10/bluetooth-btusb-add-support-for-dynex-insignia-usb-dongles.patch b/queue-3.10/bluetooth-btusb-add-support-for-dynex-insignia-usb-dongles.patch new file mode 100644 index 00000000000..1fffe84890c --- /dev/null +++ b/queue-3.10/bluetooth-btusb-add-support-for-dynex-insignia-usb-dongles.patch @@ -0,0 +1,138 @@ +From d049f4e513e861167361b06c7ca85f9e872c8cde Mon Sep 17 00:00:00 2001 +From: Marcel Holtmann +Date: Mon, 26 Jan 2015 20:35:32 -0800 +Subject: Bluetooth: btusb: Add support for Dynex/Insignia USB dongles + +From: Marcel Holtmann + +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 +Signed-off-by: Johan Hedberg +Signed-off-by: Greg Kroah-Hartman + +--- + 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 struct usb_device_id btusb_table[ + { 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) }, + diff --git a/queue-3.10/fsnotify-fix-handling-of-renames-in-audit.patch b/queue-3.10/fsnotify-fix-handling-of-renames-in-audit.patch new file mode 100644 index 00000000000..229873d0e62 --- /dev/null +++ b/queue-3.10/fsnotify-fix-handling-of-renames-in-audit.patch @@ -0,0 +1,79 @@ +From 6ee8e25fc3e916193bce4ebb43d5439e1e2144ab Mon Sep 17 00:00:00 2001 +From: Jan Kara +Date: Tue, 10 Feb 2015 14:08:32 -0800 +Subject: fsnotify: fix handling of renames in audit + +From: Jan Kara + +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 +Cc: Paul Moore +Cc: Eric Paris +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + 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); diff --git a/queue-3.10/hid-i2c-hid-limit-reads-to-wmaxinputlength-bytes-for-input-events.patch b/queue-3.10/hid-i2c-hid-limit-reads-to-wmaxinputlength-bytes-for-input-events.patch new file mode 100644 index 00000000000..3185045ca29 --- /dev/null +++ b/queue-3.10/hid-i2c-hid-limit-reads-to-wmaxinputlength-bytes-for-input-events.patch @@ -0,0 +1,41 @@ +From 6d00f37e49d95e640a3937a4a1ae07dbe92a10cb Mon Sep 17 00:00:00 2001 +From: Seth Forshee +Date: Fri, 20 Feb 2015 11:45:11 -0600 +Subject: HID: i2c-hid: Limit reads to wMaxInputLength bytes for input events + +From: Seth Forshee + +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 +Reviewed-by: Benjamin Tissoires +Signed-off-by: Jiri Kosina +Signed-off-by: Greg Kroah-Hartman + +--- + 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 +@@ -341,7 +341,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) { diff --git a/queue-3.10/iwlwifi-mvm-always-use-mac-color-zero.patch b/queue-3.10/iwlwifi-mvm-always-use-mac-color-zero.patch new file mode 100644 index 00000000000..36164441428 --- /dev/null +++ b/queue-3.10/iwlwifi-mvm-always-use-mac-color-zero.patch @@ -0,0 +1,37 @@ +From 5523d11cc46393a1e61b7ef4a0b2d4e7ed9521e4 Mon Sep 17 00:00:00 2001 +From: Luciano Coelho +Date: Thu, 29 Jan 2015 12:48:20 +0200 +Subject: iwlwifi: mvm: always use mac color zero + +From: Luciano Coelho + +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 +Reviewed-by: Johannes Berg +Signed-off-by: Emmanuel Grumbach +Signed-off-by: Greg Kroah-Hartman + +--- + 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 +@@ -360,9 +360,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); diff --git a/queue-3.10/iwlwifi-mvm-fix-failure-path-when-power_update-fails-in-add_interface.patch b/queue-3.10/iwlwifi-mvm-fix-failure-path-when-power_update-fails-in-add_interface.patch new file mode 100644 index 00000000000..680b4203f3f --- /dev/null +++ b/queue-3.10/iwlwifi-mvm-fix-failure-path-when-power_update-fails-in-add_interface.patch @@ -0,0 +1,33 @@ +From fd66fc1cafd72ddf27dbec3a5e29e99839d1bc84 Mon Sep 17 00:00:00 2001 +From: Luciano Coelho +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 + +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 +Reviewed-by: Johannes Berg +Signed-off-by: Emmanuel Grumbach +Signed-off-by: Greg Kroah-Hartman + +--- + 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 +@@ -544,7 +544,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; + + /* + * Update power state on the new interface. Admittedly, based on diff --git a/queue-3.10/iwlwifi-mvm-validate-tid-and-sta_id-in-ba_notif.patch b/queue-3.10/iwlwifi-mvm-validate-tid-and-sta_id-in-ba_notif.patch new file mode 100644 index 00000000000..d71d3c2c7d0 --- /dev/null +++ b/queue-3.10/iwlwifi-mvm-validate-tid-and-sta_id-in-ba_notif.patch @@ -0,0 +1,35 @@ +From 2cee4762c528a9bd2cdff793197bf591a2196c11 Mon Sep 17 00:00:00 2001 +From: Eyal Shapira +Date: Fri, 16 Jan 2015 11:09:30 +0200 +Subject: iwlwifi: mvm: validate tid and sta_id in ba_notif + +From: Eyal Shapira + +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 +Signed-off-by: Emmanuel Grumbach +Signed-off-by: Greg Kroah-Hartman + +--- + 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 +@@ -832,6 +832,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]); diff --git a/queue-3.10/iwlwifi-pcie-disable-the-scd_base_addr-when-we-resume-from-wowlan.patch b/queue-3.10/iwlwifi-pcie-disable-the-scd_base_addr-when-we-resume-from-wowlan.patch new file mode 100644 index 00000000000..25419f35a07 --- /dev/null +++ b/queue-3.10/iwlwifi-pcie-disable-the-scd_base_addr-when-we-resume-from-wowlan.patch @@ -0,0 +1,53 @@ +From cd8f438405032ac8ff88bd8f2eca5e0c0063b14b Mon Sep 17 00:00:00 2001 +From: Emmanuel Grumbach +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 + +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 +Signed-off-by: Emmanuel Grumbach +Signed-off-by: Greg Kroah-Hartman + +--- + 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 +@@ -720,7 +720,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); + } + + /* diff --git a/queue-3.10/pci-fix-infinite-loop-with-rom-image-of-size-0.patch b/queue-3.10/pci-fix-infinite-loop-with-rom-image-of-size-0.patch new file mode 100644 index 00000000000..11dfc0983e0 --- /dev/null +++ b/queue-3.10/pci-fix-infinite-loop-with-rom-image-of-size-0.patch @@ -0,0 +1,54 @@ +From 16b036af31e1456cb69243a5a0c9ef801ecd1f17 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Michel=20D=C3=A4nzer?= +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?= + +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 +Signed-off-by: Michel Dänzer +Signed-off-by: Bjorn Helgaas +Reviewed-by: Alex Deucher +Signed-off-by: Greg Kroah-Hartman + +--- + 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 */ diff --git a/queue-3.10/pci-generate-uppercase-hex-for-modalias-var-in-uevent.patch b/queue-3.10/pci-generate-uppercase-hex-for-modalias-var-in-uevent.patch new file mode 100644 index 00000000000..efa61a2d05f --- /dev/null +++ b/queue-3.10/pci-generate-uppercase-hex-for-modalias-var-in-uevent.patch @@ -0,0 +1,47 @@ +From 145b3fe579db66fbe999a2bc3fd5b63dffe9636d Mon Sep 17 00:00:00 2001 +From: Ricardo Ribalda Delgado +Date: Tue, 2 Dec 2014 17:35:04 +0100 +Subject: PCI: Generate uppercase hex for modalias var in uevent + +From: Ricardo Ribalda Delgado + +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 +Signed-off-by: Bjorn Helgaas +Acked-by: Greg Kroah-Hartman +Signed-off-by: Greg Kroah-Hartman + +--- + 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 +@@ -1267,7 +1267,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), diff --git a/queue-3.10/series b/queue-3.10/series new file mode 100644 index 00000000000..34611bd80ff --- /dev/null +++ b/queue-3.10/series @@ -0,0 +1,13 @@ +bluetooth-ath3k-workaround-the-compatibility-issue-with-xhci-controller.patch +bluetooth-btusb-add-support-for-dynex-insignia-usb-dongles.patch +xfs-ensure-buffer-types-are-set-correctly.patch +xfs-inode-unlink-does-not-set-agi-buffer-type.patch +xfs-set-superblock-buffer-type-correctly.patch +fsnotify-fix-handling-of-renames-in-audit.patch +iwlwifi-pcie-disable-the-scd_base_addr-when-we-resume-from-wowlan.patch +iwlwifi-mvm-validate-tid-and-sta_id-in-ba_notif.patch +iwlwifi-mvm-fix-failure-path-when-power_update-fails-in-add_interface.patch +iwlwifi-mvm-always-use-mac-color-zero.patch +hid-i2c-hid-limit-reads-to-wmaxinputlength-bytes-for-input-events.patch +pci-generate-uppercase-hex-for-modalias-var-in-uevent.patch +pci-fix-infinite-loop-with-rom-image-of-size-0.patch diff --git a/queue-3.10/xfs-ensure-buffer-types-are-set-correctly.patch b/queue-3.10/xfs-ensure-buffer-types-are-set-correctly.patch new file mode 100644 index 00000000000..0c2ace803ce --- /dev/null +++ b/queue-3.10/xfs-ensure-buffer-types-are-set-correctly.patch @@ -0,0 +1,44 @@ +From 0d612fb570b71ea2e49554a770cff4c489018b2c Mon Sep 17 00:00:00 2001 +From: Dave Chinner +Date: Thu, 22 Jan 2015 09:29:05 +1100 +Subject: xfs: ensure buffer types are set correctly + +From: Dave Chinner + +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 +Tested-by: Jan Kara +Signed-off-by: Dave Chinner +Reviewed-by: Brian Foster +Signed-off-by: Dave Chinner +Signed-off-by: Greg Kroah-Hartman + +--- + 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 +@@ -296,6 +296,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 diff --git a/queue-3.10/xfs-inode-unlink-does-not-set-agi-buffer-type.patch b/queue-3.10/xfs-inode-unlink-does-not-set-agi-buffer-type.patch new file mode 100644 index 00000000000..5a7ce57f0b3 --- /dev/null +++ b/queue-3.10/xfs-inode-unlink-does-not-set-agi-buffer-type.patch @@ -0,0 +1,50 @@ +From f19b872b086711bb4b22c3a0f52f16aa920bcc61 Mon Sep 17 00:00:00 2001 +From: Dave Chinner +Date: Thu, 22 Jan 2015 09:29:40 +1100 +Subject: xfs: inode unlink does not set AGI buffer type + +From: Dave Chinner + +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 +Signed-off-by: Dave Chinner +Reviewed-by: Brian Foster +Signed-off-by: Dave Chinner +Signed-off-by: Greg Kroah-Hartman + +--- + fs/xfs/xfs_inode.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/fs/xfs/xfs_inode.c ++++ b/fs/xfs/xfs_inode.c +@@ -1655,6 +1655,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; +@@ -1746,6 +1747,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 { diff --git a/queue-3.10/xfs-set-superblock-buffer-type-correctly.patch b/queue-3.10/xfs-set-superblock-buffer-type-correctly.patch new file mode 100644 index 00000000000..6078f3752bc --- /dev/null +++ b/queue-3.10/xfs-set-superblock-buffer-type-correctly.patch @@ -0,0 +1,42 @@ +From 3443a3bca54588f43286b725d8648d33a38c86f1 Mon Sep 17 00:00:00 2001 +From: Dave Chinner +Date: Thu, 22 Jan 2015 09:30:23 +1100 +Subject: xfs: set superblock buffer type correctly + +From: Dave Chinner + +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 +Signed-off-by: Dave Chinner +Reviewed-by: Brian Foster +Signed-off-by: Dave Chinner +Signed-off-by: Greg Kroah-Hartman + +--- + fs/xfs/xfs_trans.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/fs/xfs/xfs_trans.c ++++ b/fs/xfs/xfs_trans.c +@@ -1100,6 +1100,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. diff --git a/queue-3.14/series b/queue-3.14/series new file mode 100644 index 00000000000..34611bd80ff --- /dev/null +++ b/queue-3.14/series @@ -0,0 +1,13 @@ +bluetooth-ath3k-workaround-the-compatibility-issue-with-xhci-controller.patch +bluetooth-btusb-add-support-for-dynex-insignia-usb-dongles.patch +xfs-ensure-buffer-types-are-set-correctly.patch +xfs-inode-unlink-does-not-set-agi-buffer-type.patch +xfs-set-superblock-buffer-type-correctly.patch +fsnotify-fix-handling-of-renames-in-audit.patch +iwlwifi-pcie-disable-the-scd_base_addr-when-we-resume-from-wowlan.patch +iwlwifi-mvm-validate-tid-and-sta_id-in-ba_notif.patch +iwlwifi-mvm-fix-failure-path-when-power_update-fails-in-add_interface.patch +iwlwifi-mvm-always-use-mac-color-zero.patch +hid-i2c-hid-limit-reads-to-wmaxinputlength-bytes-for-input-events.patch +pci-generate-uppercase-hex-for-modalias-var-in-uevent.patch +pci-fix-infinite-loop-with-rom-image-of-size-0.patch diff --git a/queue-3.19/series b/queue-3.19/series index 4ac2e76adda..46bfd3c1e76 100644 --- a/queue-3.19/series +++ b/queue-3.19/series @@ -1 +1,28 @@ ext4-ignore-journal-checksum-on-remount-don-t-fail.patch +bluetooth-ath3k-workaround-the-compatibility-issue-with-xhci-controller.patch +bluetooth-ath3k-add-support-of-ar3012-bluetooth-13d3-3423-device.patch +bluetooth-fix-valid-identity-address-check.patch +bluetooth-btusb-add-broadcom-patchram-support-for-asustek-devices.patch +bluetooth-fix-reporting-invalid-rssi-for-le-devices.patch +bluetooth-btusb-add-support-for-dynex-insignia-usb-dongles.patch +bluetooth-btusb-add-support-for-lite-on-04ca-broadcom-based-bcm43142.patch +random-fix-fast_mix-function.patch +xfs-ensure-buffer-types-are-set-correctly.patch +xfs-inode-unlink-does-not-set-agi-buffer-type.patch +xfs-set-buf-types-when-converting-extent-formats.patch +xfs-set-superblock-buffer-type-correctly.patch +xfs-only-trace-buffer-items-if-they-exist.patch +fsnotify-fix-handling-of-renames-in-audit.patch +ksoftirqd-enable-irqs-and-call-cond_resched-before-poking-rcu.patch +iwlwifi-pcie-disable-the-scd_base_addr-when-we-resume-from-wowlan.patch +iwlwifi-mvm-validate-tid-and-sta_id-in-ba_notif.patch +iwlwifi-mvm-fix-failure-path-when-power_update-fails-in-add_interface.patch +iwlwifi-mvm-always-use-mac-color-zero.patch +hid-i2c-hid-limit-reads-to-wmaxinputlength-bytes-for-input-events.patch +udf-check-length-of-extended-attributes-and-allocation-descriptors.patch +pci-generate-uppercase-hex-for-modalias-var-in-uevent.patch +pci-fix-infinite-loop-with-rom-image-of-size-0.patch +asoc-rt5670-set-use_single_rw-flag-for-regmap.patch +asoc-intel-sst-fix-firmware-name-size-handling.patch +asoc-rt5677-fix-spi-dependency.patch +asoc-mioa701_wm9713-fix-speaker-event.patch -- 2.47.3