--- /dev/null
+From 1fc29bacedeabb278080e31bb9c1ecb49f143c3b Mon Sep 17 00:00:00 2001
+From: Jeff Layton <jlayton@redhat.com>
+Date: Fri, 31 May 2013 10:00:18 -0400
+Subject: cifs: fix off-by-one bug in build_unc_path_to_root
+
+From: Jeff Layton <jlayton@redhat.com>
+
+commit 1fc29bacedeabb278080e31bb9c1ecb49f143c3b upstream.
+
+commit 839db3d10a (cifs: fix up handling of prefixpath= option) changed
+the code such that the vol->prepath no longer contained a leading
+delimiter and then fixed up the places that accessed that field to
+account for that change.
+
+One spot in build_unc_path_to_root was missed however. When doing the
+pointer addition on pos, that patch failed to account for the fact that
+we had already incremented "pos" by one when adding the length of the
+prepath. This caused a buffer overrun by one byte.
+
+This patch fixes the problem by correcting the handling of "pos".
+
+Reported-by: Marcus Moeller <marcus.moeller@gmx.ch>
+Reported-by: Ken Fallon <ken.fallon@gmail.com>
+Signed-off-by: Jeff Layton <jlayton@redhat.com>
+Signed-off-by: Steve French <sfrench@us.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/cifs/connect.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/fs/cifs/connect.c
++++ b/fs/cifs/connect.c
+@@ -3332,8 +3332,8 @@ build_unc_path_to_root(const struct smb_
+ pos = full_path + unc_len;
+
+ if (pplen) {
+- *pos++ = CIFS_DIR_SEP(cifs_sb);
+- strncpy(pos, vol->prepath, pplen);
++ *pos = CIFS_DIR_SEP(cifs_sb);
++ strncpy(pos + 1, vol->prepath, pplen);
+ pos += pplen;
+ }
+
--- /dev/null
+From b7ea85a4fed37835eec78a7be3039c8dc22b8178 Mon Sep 17 00:00:00 2001
+From: Huacai Chen <chenhc@lemote.com>
+Date: Tue, 21 May 2013 06:23:43 +0000
+Subject: drm: fix a use-after-free when GPU acceleration disabled
+
+From: Huacai Chen <chenhc@lemote.com>
+
+commit b7ea85a4fed37835eec78a7be3039c8dc22b8178 upstream.
+
+When GPU acceleration is disabled, drm_vblank_cleanup() will free the
+vblank-related data, such as vblank_refcount, vblank_inmodeset, etc.
+But we found that drm_vblank_post_modeset() may be called after the
+cleanup, which use vblank_refcount and vblank_inmodeset. And this will
+cause a kernel panic.
+
+Fix this by return immediately if dev->num_crtcs is zero. This is the
+same thing that drm_vblank_pre_modeset() does.
+
+Call trace of a drm_vblank_post_modeset() after drm_vblank_cleanup():
+[ 62.628906] [<ffffffff804868d0>] drm_vblank_post_modeset+0x34/0xb4
+[ 62.628906] [<ffffffff804c7008>] atombios_crtc_dpms+0xb4/0x174
+[ 62.628906] [<ffffffff804c70e0>] atombios_crtc_commit+0x18/0x38
+[ 62.628906] [<ffffffff8047f038>] drm_crtc_helper_set_mode+0x304/0x3cc
+[ 62.628906] [<ffffffff8047f92c>] drm_crtc_helper_set_config+0x6d8/0x988
+[ 62.628906] [<ffffffff8047dd40>] drm_fb_helper_set_par+0x94/0x104
+[ 62.628906] [<ffffffff80439d14>] fbcon_init+0x424/0x57c
+[ 62.628906] [<ffffffff8046a638>] visual_init+0xb8/0x118
+[ 62.628906] [<ffffffff8046b9f8>] take_over_console+0x238/0x384
+[ 62.628906] [<ffffffff80436df8>] fbcon_takeover+0x7c/0xdc
+[ 62.628906] [<ffffffff8024fa20>] notifier_call_chain+0x44/0x94
+[ 62.628906] [<ffffffff8024fcbc>] __blocking_notifier_call_chain+0x48/0x68
+[ 62.628906] [<ffffffff8042d990>] register_framebuffer+0x228/0x260
+[ 62.628906] [<ffffffff8047e010>] drm_fb_helper_single_fb_probe+0x260/0x314
+[ 62.628906] [<ffffffff8047e2c4>] drm_fb_helper_initial_config+0x200/0x234
+[ 62.628906] [<ffffffff804e5560>] radeon_fbdev_init+0xd4/0xf4
+[ 62.628906] [<ffffffff804e0e08>] radeon_modeset_init+0x9bc/0xa18
+[ 62.628906] [<ffffffff804bfc14>] radeon_driver_load_kms+0xdc/0x12c
+[ 62.628906] [<ffffffff8048b548>] drm_get_pci_dev+0x148/0x238
+[ 62.628906] [<ffffffff80423564>] local_pci_probe+0x5c/0xd0
+[ 62.628906] [<ffffffff80241ac4>] work_for_cpu_fn+0x1c/0x30
+[ 62.628906] [<ffffffff802427c8>] process_one_work+0x274/0x3bc
+[ 62.628906] [<ffffffff80242934>] process_scheduled_works+0x24/0x44
+[ 62.628906] [<ffffffff8024515c>] worker_thread+0x31c/0x3f4
+[ 62.628906] [<ffffffff802497a8>] kthread+0x88/0x90
+[ 62.628906] [<ffffffff80206794>] kernel_thread_helper+0x10/0x18
+
+Signed-off-by: Huacai Chen <chenhc@lemote.com>
+Signed-off-by: Binbin Zhou <zhoubb@lemote.com>
+Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
+Acked-by: Paul Menzel <paulepanter@users.sourceforge.net>
+Signed-off-by: Dave Airlie <airlied@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/drm_irq.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/drm_irq.c
++++ b/drivers/gpu/drm/drm_irq.c
+@@ -1054,7 +1054,7 @@ EXPORT_SYMBOL(drm_vblank_off);
+ */
+ void drm_vblank_pre_modeset(struct drm_device *dev, int crtc)
+ {
+- /* vblank is not initialized (IRQ not installed ?) */
++ /* vblank is not initialized (IRQ not installed ?), or has been freed */
+ if (!dev->num_crtcs)
+ return;
+ /*
+@@ -1076,6 +1076,10 @@ void drm_vblank_post_modeset(struct drm_
+ {
+ unsigned long irqflags;
+
++ /* vblank is not initialized (IRQ not installed ?), or has been freed */
++ if (!dev->num_crtcs)
++ return;
++
+ if (dev->vblank_inmodeset[crtc]) {
+ spin_lock_irqsave(&dev->vbl_lock, irqflags);
+ dev->vblank_disable_allowed = 1;
--- /dev/null
+From 7abb690a0e095717420ba78dcab4309abbbec78a Mon Sep 17 00:00:00 2001
+From: Daniel Vetter <daniel.vetter@ffwll.ch>
+Date: Fri, 24 May 2013 21:29:32 +0200
+Subject: drm/i915: Fix spurious -EIO/SIGBUS on wedged gpus
+
+From: Daniel Vetter <daniel.vetter@ffwll.ch>
+
+commit 7abb690a0e095717420ba78dcab4309abbbec78a upstream.
+
+Chris Wilson noticed that since
+
+commit 1f83fee08d625f8d0130f9fe5ef7b17c2e022f3c [v3.9]
+Author: Daniel Vetter <daniel.vetter@ffwll.ch>
+Date: Thu Nov 15 17:17:22 2012 +0100
+
+ drm/i915: clear up wedged transitions
+
+X can again get -EIO when it does not expect it. And even worse score
+a SIGBUS when accessing gtt mmaps. The established ABI is that we
+_only_ return an -EIO from execbuf - all other ioctls should just
+work. And since the reset code moves all bos out of gpu domains and
+clears out all the last_seqno/ring tracking there really shouldn't be
+any reason for non-execbuf code to ever touch the hw and see an -EIO.
+
+After some extensive discussions we've noticed that these spurios -EIO
+are caused by i915_gem_wait_for_error:
+
+http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg20540.html
+
+That is easy to fix by returning 0 instead of -EIO, since grabbing the
+dev->struct_mutex does not yet mean that we actually want to touch the
+hw. And so there is no reason at all to fail with -EIO.
+
+But that's not the entire since, since often (at least it's easily
+googleable) dmesg indicates that the reset fails and we declare the
+gpu wedged. Then, quite a bit later X wakes up with the "Timed out
+waiting for the gpu reset to complete" DRM_ERROR message in
+wait_for_errror and brings down the desktop with an -EIO/SIGBUS.
+
+So clearly we're missing a wakeup somewhere, since the gpu reset just
+doesn't take 10 seconds to complete. And indeed we're do handle the
+terminally wedged state wrong.
+
+Fix this all up.
+
+References: https://bugs.freedesktop.org/show_bug.cgi?id=63921
+References: https://bugs.freedesktop.org/show_bug.cgi?id=64073
+Cc: Chris Wilson <chris@chris-wilson.co.uk>
+Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
+Cc: Damien Lespiau <damien.lespiau@intel.com>
+Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
+Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/i915_gem.c | 7 ++-----
+ 1 file changed, 2 insertions(+), 5 deletions(-)
+
+--- a/drivers/gpu/drm/i915/i915_gem.c
++++ b/drivers/gpu/drm/i915/i915_gem.c
+@@ -91,14 +91,11 @@ i915_gem_wait_for_error(struct i915_gpu_
+ {
+ int ret;
+
+-#define EXIT_COND (!i915_reset_in_progress(error))
++#define EXIT_COND (!i915_reset_in_progress(error) || \
++ i915_terminally_wedged(error))
+ if (EXIT_COND)
+ return 0;
+
+- /* GPU is already declared terminally dead, give up. */
+- if (i915_terminally_wedged(error))
+- return -EIO;
+-
+ /*
+ * Only wait 10 seconds for the gpu reset to complete to avoid hanging
+ * userspace. If it takes that long something really bad is going on and
--- /dev/null
+From 45a211d75137b1ac869a8a758a6667f15827a115 Mon Sep 17 00:00:00 2001
+From: Ben Mesman <ben@bnc.nl>
+Date: Tue, 16 Apr 2013 20:00:28 +0200
+Subject: drm/i915: no lvds quirk for hp t5740
+
+From: Ben Mesman <ben@bnc.nl>
+
+commit 45a211d75137b1ac869a8a758a6667f15827a115 upstream.
+
+Last year, a patch was made for the "HP t5740e Thin Client" (see
+http://lists.freedesktop.org/archives/dri-devel/2012-May/023245.html).
+This device reports an lvds panel, but does not really have one.
+
+The predecessor of this device is the "hp t5740", which also does not have
+an lvds panel. This patch will add the same quirk for this device.
+
+Signed-off-by: Ben Mesman <ben@bnc.nl>
+Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/intel_lvds.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpu/drm/i915/intel_lvds.c
++++ b/drivers/gpu/drm/i915/intel_lvds.c
+@@ -803,10 +803,10 @@ static const struct dmi_system_id intel_
+ },
+ {
+ .callback = intel_no_lvds_dmi_callback,
+- .ident = "Hewlett-Packard HP t5740e Thin Client",
++ .ident = "Hewlett-Packard HP t5740",
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "Hewlett-Packard"),
+- DMI_MATCH(DMI_PRODUCT_NAME, "HP t5740e Thin Client"),
++ DMI_MATCH(DMI_PRODUCT_NAME, " t5740"),
+ },
+ },
+ {
--- /dev/null
+From 53d3b4d7778daf15900867336c85d3f8dd70600c Mon Sep 17 00:00:00 2001
+From: Egbert Eich <eich@suse.de>
+Date: Tue, 4 Jun 2013 17:13:21 +0200
+Subject: drm/i915/sdvo: Use &intel_sdvo->ddc instead of intel_sdvo->i2c for DDC.
+
+From: Egbert Eich <eich@suse.de>
+
+commit 53d3b4d7778daf15900867336c85d3f8dd70600c upstream.
+
+In intel_sdvo_get_lvds_modes() the wrong i2c adapter record is used
+for DDC. Thus the code will always have to rely on a LVDS panel
+mode supplied by VBT.
+In most cases this succeeds, so this didn't get detected for quite
+a while.
+
+This regression seems to have been introduced in
+
+commit f899fc64cda8569d0529452aafc0da31c042df2e
+Author: Chris Wilson <chris@chris-wilson.co.uk>
+Date: Tue Jul 20 15:44:45 2010 -0700
+
+ drm/i915: use GMBUS to manage i2c links
+
+Signed-off-by: Egbert Eich <eich@suse.de>
+Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
+[danvet: Add note about which commit likely introduced this issue.]
+Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/intel_sdvo.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/i915/intel_sdvo.c
++++ b/drivers/gpu/drm/i915/intel_sdvo.c
+@@ -1770,7 +1770,7 @@ static void intel_sdvo_get_lvds_modes(st
+ * Assume that the preferred modes are
+ * arranged in priority order.
+ */
+- intel_ddc_get_modes(connector, intel_sdvo->i2c);
++ intel_ddc_get_modes(connector, &intel_sdvo->ddc);
+ if (list_empty(&connector->probed_modes) == false)
+ goto end;
+
--- /dev/null
+From 91f8f105f2b82b4a38dee2d74760bc39d40ec42c Mon Sep 17 00:00:00 2001
+From: Christopher Harvey <charvey@matrox.com>
+Date: Fri, 31 May 2013 20:33:07 +0000
+Subject: drm/mgag200: Add missing write to index before accessing data register
+
+From: Christopher Harvey <charvey@matrox.com>
+
+commit 91f8f105f2b82b4a38dee2d74760bc39d40ec42c upstream.
+
+This is a bug fix for some versions of g200se cards while doing
+mode-setting.
+
+Signed-off-by: Christopher Harvey <charvey@matrox.com>
+Tested-by: Julia Lemire <jlemire@matrox.com>
+Acked-by: Julia Lemire <jlemire@matrox.com>
+Signed-off-by: Dave Airlie <airlied@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/mgag200/mgag200_mode.c | 9 +++++----
+ 1 file changed, 5 insertions(+), 4 deletions(-)
+
+--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
++++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
+@@ -1041,13 +1041,14 @@ static int mga_crtc_mode_set(struct drm_
+ else
+ hi_pri_lvl = 5;
+
+- WREG8(0x1fde, 0x06);
+- WREG8(0x1fdf, hi_pri_lvl);
++ WREG8(MGAREG_CRTCEXT_INDEX, 0x06);
++ WREG8(MGAREG_CRTCEXT_DATA, hi_pri_lvl);
+ } else {
++ WREG8(MGAREG_CRTCEXT_INDEX, 0x06);
+ if (mdev->reg_1e24 >= 0x01)
+- WREG8(0x1fdf, 0x03);
++ WREG8(MGAREG_CRTCEXT_DATA, 0x03);
+ else
+- WREG8(0x1fdf, 0x04);
++ WREG8(MGAREG_CRTCEXT_DATA, 0x04);
+ }
+ }
+ return 0;
--- /dev/null
+From bc5abcf7e411b889f73ea2a90439071a0f451011 Mon Sep 17 00:00:00 2001
+From: Tyler Hicks <tyhicks@canonical.com>
+Date: Tue, 4 Jun 2013 10:24:56 -0700
+Subject: eCryptfs: Check return of filemap_write_and_wait during fsync
+
+From: Tyler Hicks <tyhicks@canonical.com>
+
+commit bc5abcf7e411b889f73ea2a90439071a0f451011 upstream.
+
+Error out of ecryptfs_fsync() if filemap_write_and_wait() fails.
+
+Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
+Cc: Paul Taysom <taysom@chromium.org>
+Cc: Olof Johansson <olofj@chromium.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/ecryptfs/file.c | 7 ++++++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+--- a/fs/ecryptfs/file.c
++++ b/fs/ecryptfs/file.c
+@@ -294,7 +294,12 @@ static int ecryptfs_release(struct inode
+ static int
+ ecryptfs_fsync(struct file *file, loff_t start, loff_t end, int datasync)
+ {
+- filemap_write_and_wait(file->f_mapping);
++ int rc;
++
++ rc = filemap_write_and_wait(file->f_mapping);
++ if (rc)
++ return rc;
++
+ return vfs_fsync(ecryptfs_file_to_lower(file), datasync);
+ }
+
--- /dev/null
+From c15cddd900e867c5adfb3c79596479dc5975f743 Mon Sep 17 00:00:00 2001
+From: Paul Taysom <taysom@chromium.org>
+Date: Thu, 23 May 2013 14:31:43 -0700
+Subject: ecryptfs: fixed msync to flush data
+
+From: Paul Taysom <taysom@chromium.org>
+
+commit c15cddd900e867c5adfb3c79596479dc5975f743 upstream.
+
+When msync is called on a memory mapped file, that
+data is not flushed to the disk.
+
+In Linux, msync calls fsync for the file. For ecryptfs,
+fsync just calls the lower level file system's fsync.
+Changed the ecryptfs fsync code to call filemap_write_and_wait
+before calling the lower level fsync.
+
+Addresses the problem described in http://crbug.com/239536
+
+Signed-off-by: Paul Taysom <taysom@chromium.org>
+Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/ecryptfs/file.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/fs/ecryptfs/file.c
++++ b/fs/ecryptfs/file.c
+@@ -294,6 +294,7 @@ static int ecryptfs_release(struct inode
+ static int
+ ecryptfs_fsync(struct file *file, loff_t start, loff_t end, int datasync)
+ {
++ filemap_write_and_wait(file->f_mapping);
+ return vfs_fsync(ecryptfs_file_to_lower(file), datasync);
+ }
+
--- /dev/null
+From bbd465df73f0d8ba41b8a0732766a243d0f5b356 Mon Sep 17 00:00:00 2001
+From: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
+Date: Sun, 9 Jun 2013 01:25:57 +0200
+Subject: hpfs: fix warnings when the filesystem fills up
+
+From: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
+
+commit bbd465df73f0d8ba41b8a0732766a243d0f5b356 upstream.
+
+This patch fixes warnings due to missing lock on write error path.
+
+ WARNING: at fs/hpfs/hpfs_fn.h:353 hpfs_truncate+0x75/0x80 [hpfs]()
+ Hardware name: empty
+ Pid: 26563, comm: dd Tainted: P O 3.9.4 #12
+ Call Trace:
+ hpfs_truncate+0x75/0x80 [hpfs]
+ hpfs_write_begin+0x84/0x90 [hpfs]
+ _hpfs_bmap+0x10/0x10 [hpfs]
+ generic_file_buffered_write+0x121/0x2c0
+ __generic_file_aio_write+0x1c7/0x3f0
+ generic_file_aio_write+0x7c/0x100
+ do_sync_write+0x98/0xd0
+ hpfs_file_write+0xd/0x50 [hpfs]
+ vfs_write+0xa2/0x160
+ sys_write+0x51/0xa0
+ page_fault+0x22/0x30
+ system_call_fastpath+0x1a/0x1f
+
+Signed-off-by: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/hpfs/file.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/fs/hpfs/file.c
++++ b/fs/hpfs/file.c
+@@ -109,10 +109,14 @@ static void hpfs_write_failed(struct add
+ {
+ struct inode *inode = mapping->host;
+
++ hpfs_lock(inode->i_sb);
++
+ if (to > inode->i_size) {
+ truncate_pagecache(inode, to, inode->i_size);
+ hpfs_truncate(inode);
+ }
++
++ hpfs_unlock(inode->i_sb);
+ }
+
+ static int hpfs_write_begin(struct file *file, struct address_space *mapping,
--- /dev/null
+From 591bfcfc334a003ba31c0deff03b22e73349939b Mon Sep 17 00:00:00 2001
+From: Guenter Roeck <linux@roeck-us.net>
+Date: Wed, 5 Jun 2013 14:09:30 -0700
+Subject: hwmon: (adm1021) Strengthen chip detection for ADM1021, LM84 and MAX1617
+
+From: Guenter Roeck <linux@roeck-us.net>
+
+commit 591bfcfc334a003ba31c0deff03b22e73349939b upstream.
+
+On a system with both MAX1617 and JC42 sensors, JC42 sensors can be misdetected
+as LM84. Strengthen detection sufficiently enough to avoid this misdetection.
+Also improve detection for ADM1021.
+
+Modeled after chip detection code in sensors-detect command.
+
+Signed-off-by: Guenter Roeck <linux@roeck-us.net>
+Tested-by: Jean Delvare <khali@linux-fr.org>
+Acked-by: Jean Delvare <khali@linux-fr.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/hwmon/adm1021.c | 58 +++++++++++++++++++++++++++++++++++++++++-------
+ 1 file changed, 50 insertions(+), 8 deletions(-)
+
+--- a/drivers/hwmon/adm1021.c
++++ b/drivers/hwmon/adm1021.c
+@@ -332,26 +332,68 @@ static int adm1021_detect(struct i2c_cli
+ man_id = i2c_smbus_read_byte_data(client, ADM1021_REG_MAN_ID);
+ dev_id = i2c_smbus_read_byte_data(client, ADM1021_REG_DEV_ID);
+
++ if (man_id < 0 || dev_id < 0)
++ return -ENODEV;
++
+ if (man_id == 0x4d && dev_id == 0x01)
+ type_name = "max1617a";
+ else if (man_id == 0x41) {
+ if ((dev_id & 0xF0) == 0x30)
+ type_name = "adm1023";
+- else
++ else if ((dev_id & 0xF0) == 0x00)
+ type_name = "adm1021";
++ else
++ return -ENODEV;
+ } else if (man_id == 0x49)
+ type_name = "thmc10";
+ else if (man_id == 0x23)
+ type_name = "gl523sm";
+ else if (man_id == 0x54)
+ type_name = "mc1066";
+- /* LM84 Mfr ID in a different place, and it has more unused bits */
+- else if (conv_rate == 0x00
+- && (config & 0x7F) == 0x00
+- && (status & 0xAB) == 0x00)
+- type_name = "lm84";
+- else
+- type_name = "max1617";
++ else {
++ int lte, rte, lhi, rhi, llo, rlo;
++
++ /* extra checks for LM84 and MAX1617 to avoid misdetections */
++
++ llo = i2c_smbus_read_byte_data(client, ADM1021_REG_THYST_R(0));
++ rlo = i2c_smbus_read_byte_data(client, ADM1021_REG_THYST_R(1));
++
++ /* fail if any of the additional register reads failed */
++ if (llo < 0 || rlo < 0)
++ return -ENODEV;
++
++ lte = i2c_smbus_read_byte_data(client, ADM1021_REG_TEMP(0));
++ rte = i2c_smbus_read_byte_data(client, ADM1021_REG_TEMP(1));
++ lhi = i2c_smbus_read_byte_data(client, ADM1021_REG_TOS_R(0));
++ rhi = i2c_smbus_read_byte_data(client, ADM1021_REG_TOS_R(1));
++
++ /*
++ * Fail for negative temperatures and negative high limits.
++ * This check also catches read errors on the tested registers.
++ */
++ if ((s8)lte < 0 || (s8)rte < 0 || (s8)lhi < 0 || (s8)rhi < 0)
++ return -ENODEV;
++
++ /* fail if all registers hold the same value */
++ if (lte == rte && lte == lhi && lte == rhi && lte == llo
++ && lte == rlo)
++ return -ENODEV;
++
++ /*
++ * LM84 Mfr ID is in a different place,
++ * and it has more unused bits.
++ */
++ if (conv_rate == 0x00
++ && (config & 0x7F) == 0x00
++ && (status & 0xAB) == 0x00) {
++ type_name = "lm84";
++ } else {
++ /* fail if low limits are larger than high limits */
++ if ((s8)llo > lhi || (s8)rlo > rhi)
++ return -ENODEV;
++ type_name = "max1617";
++ }
++ }
+
+ pr_debug("adm1021: Detected chip %s at adapter %d, address 0x%02x.\n",
+ type_name, i2c_adapter_id(adapter), client->addr);
--- /dev/null
+From ea7f665612fcc73da6b7698f468cd5fc03a30d47 Mon Sep 17 00:00:00 2001
+From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
+Date: Sat, 8 Jun 2013 02:55:07 +0200
+Subject: Revert "ACPI / scan: do not match drivers against objects having scan handlers"
+
+From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
+
+commit ea7f665612fcc73da6b7698f468cd5fc03a30d47 upstream.
+
+Commit 9f29ab11ddbf ("ACPI / scan: do not match drivers against objects
+having scan handlers") introduced a boot regression on Tony's ia64 HP
+rx2600. Tony says:
+
+ "It panics with the message:
+
+ Kernel panic - not syncing: Unable to find SBA IOMMU: Try a generic or DIG kernel
+
+ [...] my problem comes from arch/ia64/hp/common/sba_iommu.c
+ where the code in sba_init() says:
+
+ acpi_bus_register_driver(&acpi_sba_ioc_driver);
+ if (!ioc_list) {
+
+ but because of this change we never managed to call ioc_init()
+ so ioc_list doesn't get set up, and we die."
+
+Revert it to avoid this breakage and we'll fix the problem it attempted
+to address later.
+
+Reported-by: Tony Luck <tony.luck@gmail.com>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/acpi/scan.c | 4 ----
+ 1 file changed, 4 deletions(-)
+
+--- a/drivers/acpi/scan.c
++++ b/drivers/acpi/scan.c
+@@ -553,10 +553,6 @@ static int acpi_bus_match(struct device
+ struct acpi_device *acpi_dev = to_acpi_device(dev);
+ struct acpi_driver *acpi_drv = to_acpi_driver(drv);
+
+- /* Skip ACPI device objects with scan handlers attached. */
+- if (acpi_dev->handler)
+- return 0;
+-
+ return acpi_dev->flags.match_driver
+ && !acpi_match_device_ids(acpi_dev, acpi_drv->ids);
+ }
dmaengine-ste_dma40-fix-pm-runtime-ref-counting.patch
radeon-fix-system-hang-issue-when-using-kms-with-older-cards.patch
drm-radeon-don-t-allow-audio-on-dce6.patch
+hpfs-fix-warnings-when-the-filesystem-fills-up.patch
+cifs-fix-off-by-one-bug-in-build_unc_path_to_root.patch
+ecryptfs-fixed-msync-to-flush-data.patch
+ecryptfs-check-return-of-filemap_write_and_wait-during-fsync.patch
+hwmon-adm1021-strengthen-chip-detection-for-adm1021-lm84-and-max1617.patch
+drm-mgag200-add-missing-write-to-index-before-accessing-data-register.patch
+drm-fix-a-use-after-free-when-gpu-acceleration-disabled.patch
+drm-i915-sdvo-use-intel_sdvo-ddc-instead-of-intel_sdvo-i2c-for-ddc.patch
+drm-i915-no-lvds-quirk-for-hp-t5740.patch
+drm-i915-fix-spurious-eio-sigbus-on-wedged-gpus.patch
+revert-acpi-scan-do-not-match-drivers-against-objects-having-scan-handlers.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
