summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorZefan Li <lizefan@huawei.com>2015-06-15 10:01:47 +0800
committerZefan Li <lizefan@huawei.com>2015-06-15 10:01:47 +0800
commitaef3acc7d1c39a6b9cb7c8176e5ce5d27d8b6240 (patch)
tree014dff556cb269c236f7e4ca6fe7762c3f91e981
parent046be03d11e7e75b8f2dda34d92e62cfbb259fd8 (diff)
downloadlinux-3.4.y-queue-aef3acc7d1c39a6b9cb7c8176e5ce5d27d8b6240.tar.gz
Remove firmware-dmi_scan-fix-dmi_len-type.patch
-rw-r--r--patches/firmware-dmi_scan-fix-dmi_len-type.patch45
-rw-r--r--patches/series1
2 files changed, 0 insertions, 46 deletions
diff --git a/patches/firmware-dmi_scan-fix-dmi_len-type.patch b/patches/firmware-dmi_scan-fix-dmi_len-type.patch
deleted file mode 100644
index 9036673..0000000
--- a/patches/firmware-dmi_scan-fix-dmi_len-type.patch
+++ /dev/null
@@ -1,45 +0,0 @@
-From 6d9ff473317245e3e5cd9922b4520411c2296388 Mon Sep 17 00:00:00 2001
-From: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
-Date: Wed, 18 Feb 2015 13:33:19 +0200
-Subject: firmware: dmi_scan: Fix dmi_len type
-
-commit 6d9ff473317245e3e5cd9922b4520411c2296388 upstream.
-
-According to SMBIOSv3 specification the length of DMI table can be
-up to 32bits wide. So use appropriate type to avoid overflow.
-
-It's obvious that dmi_num theoretically can be more than u16 also,
-so it's can be changed to u32 or at least it's better to use int
-instead of u16, but on that moment I cannot imagine dmi structure
-count more than 65535 and it can require changing type of vars that
-work with it. So I didn't correct it.
-
-Acked-by: Ard Biesheuvel <ard@linaro.org>
-Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
-Signed-off-by: Matt Fleming <matt.fleming@intel.com>
-[lizf: Backported to 3.4: adjust context]
-Signed-off-by: Zefan Li <lizefan@huawei.com>
----
- drivers/firmware/dmi_scan.c | 4 ++--
- 1 file changed, 2 insertions(+), 2 deletions(-)
-
---- a/drivers/firmware/dmi_scan.c
-+++ b/drivers/firmware/dmi_scan.c
-@@ -69,7 +69,7 @@ static char * __init dmi_string(const st
- * We have to be cautious here. We have seen BIOSes with DMI pointers
- * pointing to completely the wrong place for example
- */
--static void dmi_table(u8 *buf, int len, int num,
-+static void dmi_table(u8 *buf, u32 len, int num,
- void (*decode)(const struct dmi_header *, void *),
- void *private_data)
- {
-@@ -99,7 +99,7 @@ static void dmi_table(u8 *buf, int len,
- }
-
- static u32 dmi_base;
--static u16 dmi_len;
-+static u32 dmi_len;
- static u16 dmi_num;
-
- static int __init dmi_walk_early(void (*decode)(const struct dmi_header *,
diff --git a/patches/series b/patches/series
index 7d75780..d5f58fe 100644
--- a/patches/series
+++ b/patches/series
@@ -53,7 +53,6 @@ team-fix-possible-null-pointer-dereference-in-team_handle_frame.patch
kvm-emulate-fix-cmpxchg8b-on-32-bit-hosts.patch
xhci-allocate-correct-amount-of-scratchpad-buffers.patch
usb-usbfs-don-t-leak-kernel-data-in-siginfo.patch
-firmware-dmi_scan-fix-dmi_len-type.patch
usb-ftdi_sio-add-pids-for-actisense-usb-devices.patch
usb-serial-fix-potential-use-after-free-after-failed-probe.patch
usb-serial-fix-tty-device-error-handling-at-probe.patch