--- /dev/null
+From a34eb503742fd25155fd6cff6163daacead9fbc3 Mon Sep 17 00:00:00 2001
+From: Theodore Ts'o <tytso@mit.edu>
+Date: Fri, 26 Jul 2013 15:15:46 -0400
+Subject: ext4: make sure group number is bumped after a inode allocation race
+
+From: Theodore Ts'o <tytso@mit.edu>
+
+commit a34eb503742fd25155fd6cff6163daacead9fbc3 upstream.
+
+When we try to allocate an inode, and there is a race between two
+CPU's trying to grab the same inode, _and_ this inode is the last free
+inode in the block group, make sure the group number is bumped before
+we continue searching the rest of the block groups. Otherwise, we end
+up searching the current block group twice, and we end up skipping
+searching the last block group. So in the unlikely situation where
+almost all of the inodes are allocated, it's possible that we will
+return ENOSPC even though there might be free inodes in that last
+block group.
+
+Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/ext4/ialloc.c | 10 +++++-----
+ 1 file changed, 5 insertions(+), 5 deletions(-)
+
+--- a/fs/ext4/ialloc.c
++++ b/fs/ext4/ialloc.c
+@@ -687,11 +687,8 @@ repeat_in_this_group:
+ ino = ext4_find_next_zero_bit((unsigned long *)
+ inode_bitmap_bh->b_data,
+ EXT4_INODES_PER_GROUP(sb), ino);
+- if (ino >= EXT4_INODES_PER_GROUP(sb)) {
+- if (++group == ngroups)
+- group = 0;
+- continue;
+- }
++ if (ino >= EXT4_INODES_PER_GROUP(sb))
++ goto next_group;
+ if (group == 0 && (ino+1) < EXT4_FIRST_INO(sb)) {
+ ext4_error(sb, "reserved inode found cleared - "
+ "inode=%lu", ino + 1);
+@@ -709,6 +706,9 @@ repeat_in_this_group:
+ goto got; /* we grabbed the inode! */
+ if (ino < EXT4_INODES_PER_GROUP(sb))
+ goto repeat_in_this_group;
++next_group:
++ if (++group == ngroups)
++ group = 0;
+ }
+ err = -ENOSPC;
+ goto out;
--- /dev/null
+From 93d783bcca69bfacc8dc739d8a050498402587b5 Mon Sep 17 00:00:00 2001
+From: Curt Brune <curt@cumulusnetworks.com>
+Date: Thu, 8 Aug 2013 12:11:03 -0700
+Subject: hwmon: (adt7470) Fix incorrect return code check
+
+From: Curt Brune <curt@cumulusnetworks.com>
+
+commit 93d783bcca69bfacc8dc739d8a050498402587b5 upstream.
+
+In adt7470_write_word_data(), which writes two bytes using
+i2c_smbus_write_byte_data(), the return codes are incorrectly AND-ed
+together when they should be OR-ed together.
+
+The return code of i2c_smbus_write_byte_data() is zero for success.
+
+The upshot is only the first byte was ever written to the hardware.
+The 2nd byte was never written out.
+
+I noticed that trying to set the fan speed limits was not working
+correctly on my system. Setting the fan speed limits is the only
+code that uses adt7470_write_word_data(). After making the change
+the limit settings work and the alarms work also.
+
+Signed-off-by: Curt Brune <curt@cumulusnetworks.com>
+Signed-off-by: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/hwmon/adt7470.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/hwmon/adt7470.c
++++ b/drivers/hwmon/adt7470.c
+@@ -215,7 +215,7 @@ static inline int adt7470_write_word_dat
+ u16 value)
+ {
+ return i2c_smbus_write_byte_data(client, reg, value & 0xFF)
+- && i2c_smbus_write_byte_data(client, reg + 1, value >> 8);
++ || i2c_smbus_write_byte_data(client, reg + 1, value >> 8);
+ }
+
+ static void adt7470_init_client(struct i2c_client *client)
--- /dev/null
+From 7562523e84ddc742fe1f9db8bd76b01acca89f6b Mon Sep 17 00:00:00 2001
+From: "Martin K. Petersen" <martin.petersen@oracle.com>
+Date: Tue, 30 Jul 2013 22:58:34 -0400
+Subject: SCSI: Don't attempt to send extended INQUIRY command if skip_vpd_pages is set
+
+From: "Martin K. Petersen" <martin.petersen@oracle.com>
+
+commit 7562523e84ddc742fe1f9db8bd76b01acca89f6b upstream.
+
+If a device has the skip_vpd_pages flag set we should simply fail the
+scsi_get_vpd_page() call.
+
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Acked-by: Alan Stern <stern@rowland.harvard.edu>
+Tested-by: Stuart Foster <smf.linux@ntlworld.com>
+Signed-off-by: James Bottomley <JBottomley@Parallels.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/scsi/scsi.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/scsi/scsi.c
++++ b/drivers/scsi/scsi.c
+@@ -1025,6 +1025,9 @@ int scsi_get_vpd_page(struct scsi_device
+ {
+ int i, result;
+
++ if (sdev->skip_vpd_pages)
++ goto fail;
++
+ /* Ask for all the pages supported by this device */
+ result = scsi_vpd_inquiry(sdev, buf, 0, buf_len);
+ if (result)
--- /dev/null
+From 6431f5d7c6025f8b007af06ea090de308f7e6881 Mon Sep 17 00:00:00 2001
+From: "Sumit.Saxena@lsi.com" <Sumit.Saxena@lsi.com>
+Date: Tue, 16 Jul 2013 02:26:05 +0530
+Subject: SCSI: megaraid_sas: megaraid_sas driver init fails in kdump kernel
+
+From: "Sumit.Saxena@lsi.com" <Sumit.Saxena@lsi.com>
+
+commit 6431f5d7c6025f8b007af06ea090de308f7e6881 upstream.
+
+Problem: When Hardware IOMMU is on, megaraid_sas driver initialization fails
+in kdump kernel with LSI MegaRAID controller(device id-0x73).
+
+Actually this issue needs fix in firmware, but for firmware running in field,
+this driver fix is proposed to resolve the issue. At firmware initialization
+time, if firmware does not come to ready state, driver will reset the adapter
+and retry for firmware transition to ready state unconditionally(not only
+executed for kdump kernel).
+
+Signed-off-by: Sumit Saxena <sumit.saxena@lsi.com>
+Signed-off-by: Kashyap Desai <kashyap.desai@lsi.com>
+Signed-off-by: James Bottomley <JBottomley@Parallels.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/scsi/megaraid/megaraid_sas_base.c | 20 +++++++++++++++-----
+ 1 file changed, 15 insertions(+), 5 deletions(-)
+
+--- a/drivers/scsi/megaraid/megaraid_sas_base.c
++++ b/drivers/scsi/megaraid/megaraid_sas_base.c
+@@ -3493,11 +3493,21 @@ static int megasas_init_fw(struct megasa
+ break;
+ }
+
+- /*
+- * We expect the FW state to be READY
+- */
+- if (megasas_transition_to_ready(instance, 0))
+- goto fail_ready_state;
++ if (megasas_transition_to_ready(instance, 0)) {
++ atomic_set(&instance->fw_reset_no_pci_access, 1);
++ instance->instancet->adp_reset
++ (instance, instance->reg_set);
++ atomic_set(&instance->fw_reset_no_pci_access, 0);
++ dev_info(&instance->pdev->dev,
++ "megasas: FW restarted successfully from %s!\n",
++ __func__);
++
++ /*waitting for about 30 second before retry*/
++ ssleep(30);
++
++ if (megasas_transition_to_ready(instance, 0))
++ goto fail_ready_state;
++ }
+
+ /* Check if MSI-X is supported while in ready state */
+ msix_enable = (instance->instancet->read_fw_status_reg(reg_set) &
--- /dev/null
+scsi-don-t-attempt-to-send-extended-inquiry-command-if-skip_vpd_pages-is-set.patch
+scsi-megaraid_sas-megaraid_sas-driver-init-fails-in-kdump-kernel.patch
+ext4-make-sure-group-number-is-bumped-after-a-inode-allocation-race.patch
+hwmon-adt7470-fix-incorrect-return-code-check.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
