Skip to contentSkip to conversation

4 patches for 2.6.15

PATCH New Greg Kroah-Hartman 1 participant 8 messages Dec 16, 2005 – Dec 21, 2005

Subsystems (6)
lore
Share & tools
lore
#1 lore raw

PATCH 1/4 i2c: Fix i2c-mv64xxx compilation error

In reply to Greg Kroah-Hartman

From: "Mark A. Greer" <mgreer at mvista.com>

The busses/i2c-mv64xxx.c driver doesn't currently compile because of an incorrect argument to dev_err(). This patch fixes that.

Signed-off-by Mark A. Greer <mgreer at mvista.com>
Signed-off-by Jean Delvare <khali at linux-fr.org>
Signed-off-by Greg Kroah-Hartman <gregkh at suse.de>
---
 drivers/i2c/busses/i2c-mv64xxx.c |   11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)
drivers/i2c/busses/i2c-mv64xxx.c +6 -5
@@ -529,14 +529,15 @@ mv64xxx_i2c_probe(struct platform_device
 	i2c_set_adapdata(&drv_data->adapter, drv_data);
 
 	if (request_irq(drv_data->irq, mv64xxx_i2c_intr, 0,
-		MV64XXX_I2C_CTLR_NAME, drv_data)) {
-
-		dev_err(dev, "mv64xxx: Can't register intr handler "
-			"irq: %d\n", drv_data->irq);
+			MV64XXX_I2C_CTLR_NAME, drv_data)) {
+		dev_err(&drv_data->adapter.dev,
+			"mv64xxx: Can't register intr handler irq: %d\n",
+			drv_data->irq);
 		rc = -EINVAL;
 		goto exit_unmap_regs;
 	} else if ((rc = i2c_add_adapter(&drv_data->adapter)) != 0) {
-		dev_err(dev, "mv64xxx: Can't add i2c adapter, rc: %d\n", -rc);
+		dev_err(&drv_data->adapter.dev,
+			"mv64xxx: Can't add i2c adapter, rc: %d\n", -rc);
 		goto exit_free_irq;
 	}
 

--

#3 lore raw

PATCH 3/4 PCI: Fix dumb bug in mmconfig fix

In reply to Greg Kroah-Hartman

From: Andi Kleen <[email protected]>

Use correct address when referencing mmconfig aperture while checking for broken MCFG. This was a typo when porting the code from 64bit to 32bit. It caused oopses at boot on some ThinkPads.

Should definitely go into 2.6.15.

---
 arch/i386/pci/mmconfig.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/i386/pci/mmconfig.c +1 -1
@@ -155,7 +155,7 @@ static __init void unreachable_devices(v
 		addr = get_base_addr(0, 0, PCI_DEVFN(i, 0));
 		if (addr != 0)
 			pci_exp_set_dev_base(addr, 0, PCI_DEVFN(i, 0));
-		if (addr == 0 || readl((u32 __iomem *)addr) != val1)
+		if (addr == 0 || readl((u32 __iomem *)mmcfg_virt_addr) != val1)
 			set_bit(i, fallback_slots);
 		spin_unlock_irqrestore(&pci_config_lock, flags);
 	}

--

#2 lore raw

PATCH 2/4 PCI express must be initialized before PCI hotplug

In reply to Greg Kroah-Hartman

From: Milton Miller <[email protected]>

PCI express hotplug uses the pcieportbus driver so pcie must be initialized before hotplug/. This patch changes the link order.

---
 drivers/pci/Makefile |    7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)
drivers/pci/Makefile +3 -4
@@ -6,6 +6,9 @@ obj-y		+= access.o bus.o probe.o remove.
 			pci-driver.o search.o pci-sysfs.o rom.o setup-res.o
 obj-$(CONFIG_PROC_FS) += proc.o
 
+# Build PCI Express stuff if needed
+obj-$(CONFIG_PCIEPORTBUS) += pcie/
+
 obj-$(CONFIG_HOTPLUG) += hotplug.o
 
 # Build the PCI Hotplug drivers if we were asked to
@@ -40,7 +43,3 @@ endif
 ifeq ($(CONFIG_PCI_DEBUG),y)
 EXTRA_CFLAGS += -DDEBUG
 endif
-
-# Build PCI Express stuff if needed
-obj-$(CONFIG_PCIEPORTBUS) += pcie/
-

--

#0 lore raw

cover 4 patches for 2.6.15

Hi,

Here are 4 patches against your latest 2.6.15-git tree. They fix the following problems and should all go in for 2.6.15:
- kernel oops in pci code for some thinkpads and other boxes.
- kernel oops if pci express and pci express hotplug is built into the kernel, instead of a module.
- build breakage in a i2c driver.
- memory barriers are needed for USB uhci driver in suspend/resume path, as they were accidentally dropped in a previous patch.

thanks,

greg k-h

#4 lore raw

PATCH 4/4 UHCI: add missing memory barriers

From: Alan Stern <[email protected]>

This patch (as617) adds a couple of memory barriers that Ben H. forgot in his recent suspend/resume fix.

---
 drivers/usb/host/uhci-hcd.c |    2 ++
 1 file changed, 2 insertions(+)
drivers/usb/host/uhci-hcd.c +2 -0
@@ -717,6 +717,7 @@ static int uhci_suspend(struct usb_hcd *
 	 * at the source, so we must turn off PIRQ.
 	 */
 	pci_write_config_word(to_pci_dev(uhci_dev(uhci)), USBLEGSUP, 0);
+	mb();
 	clear_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags);
 	uhci->hc_inaccessible = 1;
 	hcd->poll_rh = 0;
@@ -738,6 +739,7 @@ static int uhci_resume(struct usb_hcd *h
 	 * really don't want to keep a stale HCD_FLAG_HW_ACCESSIBLE=0
 	 */
 	set_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags);
+	mb();
 
 	if (uhci->rh_state == UHCI_RH_RESET)	/* Dead */
 		return 0;

--

#5 lore raw

cover 2 USB patches for 2.6.15

Hi,

Here are 2 patches against your latest 2.6.15-git tree. They fix the following problems:
- bugfix to allow some USB disk enclosure devices to work properly.
- small workaround to allow suspend to continue, even if the USB driver attached to a device does not have a suspend method (this preserves the old behavior, and is annoying a lot of people.)

thanks,

greg k-h

#7 lore raw

PATCH 2/2 usbcore: allow suspend/resume even if drivers don't support it

From: Alan Stern <[email protected]>

This patch (as618) changes usbcore to prevent derailing the suspend/resume sequence when a USB driver doesn't include support for it. This is a workaround rather than a true fix; the core needs to be changed so that URB submissions from suspended drivers can be refused and outstanding URBs cancelled.

---
 drivers/usb/core/usb.c |    9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)
drivers/usb/core/usb.c +6 -3
@@ -1432,7 +1432,8 @@ static int usb_generic_suspend(struct de
 			mark_quiesced(intf);
 	} else {
 		// FIXME else if there's no suspend method, disconnect...
-		dev_warn(dev, "no %s?\n", "suspend");
+		dev_warn(dev, "no suspend for driver %s?\n", driver->name);
+		mark_quiesced(intf);
 		status = 0;
 	}
 	return status;
@@ -1460,8 +1461,10 @@ static int usb_generic_resume(struct dev
 	}
 
 	if ((dev->driver == NULL) ||
-	    (dev->driver_data == &usb_generic_driver_data))
+	    (dev->driver_data == &usb_generic_driver_data)) {
+		dev->power.power_state.event = PM_EVENT_FREEZE;
 		return 0;
+	}
 
 	intf = to_usb_interface(dev);
 	driver = to_usb_driver(dev->driver);
@@ -1481,7 +1484,7 @@ static int usb_generic_resume(struct dev
 			mark_quiesced(intf);
 		}
 	} else
-		dev_warn(dev, "no %s?\n", "resume");
+		dev_warn(dev, "no resume for driver %s?\n", driver->name);
 	return 0;
 }
 
#6 lore raw

PATCH 1/2 USB Storage: Force starget->scsi_level in usb-storage scsiglue.c

In reply to Greg Kroah-Hartman

From: Paul Walmsley <[email protected]>

When the usb-storage module forces sdev->scsi_level to SCSI_2, it should also force starget->scsi_level to the same value. Otherwise, the SCSI layer may attempt to issue SCSI-3 commands to the device, such as REPORT LUNS, which it cannot handle. This can prevent the device from working with Linux.

The AMS Venus DS3 DS2316SU2S SATA-to-SATA+USB enclosure, based on the Oxford Semiconductor OXU921S chip, requires this patch to function correctly on Linux. The enclosure reports a SCSI-3 SPC-2 command set level, but does not correctly handle the REPORT LUNS SCSI command - probably due to a bug in its firmware.

It seems likely that other USB storage enclosures with similar bugs will also benefit from this patch.

Tony Lindgren <[email protected]> collaborated in the development of this patch.

---
 drivers/usb/storage/scsiglue.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/usb/storage/scsiglue.c +2 -2
@@ -109,7 +109,7 @@ static int slave_configure(struct scsi_d
 	 * data comes from.
 	 */
 	if (sdev->scsi_level < SCSI_2)
-		sdev->scsi_level = SCSI_2;
+		sdev->scsi_level = sdev->sdev_target->scsi_level = SCSI_2;
 
 	/* According to the technical support people at Genesys Logic,
 	 * devices using their chips have problems transferring more than
@@ -162,7 +162,7 @@ static int slave_configure(struct scsi_d
 		 * a Get-Max-LUN request, we won't lose much by setting the
 		 * revision level down to 2.  The only devices that would be
 		 * affected are those with sparse LUNs. */
-		sdev->scsi_level = SCSI_2;
+		sdev->scsi_level = sdev->sdev_target->scsi_level = SCSI_2;
 
 		/* USB-IDE bridges tend to report SK = 0x04 (Non-recoverable
 		 * Hardware Error) when any low-level error occurs,