[PATCH] usb: klist_node_attached() fix

[Greg KH]

[PATCH] usb: klist_node_attached() fix

The original code looks like this:

        /* if interface was already added, bind now; else let
         * the future device_add() bind it, bypassing probe()
         */
        if (!list_empty (&dev->bus_list))
                device_bind_driver(dev);

IOW, it's checking to see if the device is attached to the bus or not
and binding the driver if it is. It's checking the device's bus list,
which will only appear empty when the device has been initialized, but
not added. It depends way too much on the driver model internals, but it
seems to be the only way to do the weird crap they want to do with
interfaces.

When I converted it to use klists, I accidentally inverted the logic,
which led to bad things happening. This patch returns the check to its
orginal value.

From: Patrick Mochel <mochel@xxxxxxxxxxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxx>

Index: gregkh-2.6/drivers/usb/core/usb.c
===================================================================

---
commit 273971bade8a6d37c1b162146de1a53965cdc245
tree ef78c4a7c1b8ab39c9b6f47fef82278d5145e74d
parent 12eac738e5889a10da5b391c02eeb61229c796dc
author Patrick Mochel <mochel@xxxxxxxxxxxxxxxxxx> Mon, 20 Jun 2005 15:15:28 -0700
committer Greg Kroah-Hartman <gregkh@xxxxxxx> Mon, 20 Jun 2005 15:15:28 -0700

 drivers/usb/core/usb.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c
--- a/drivers/usb/core/usb.c
+++ b/drivers/usb/core/usb.c
@@ -293,7 +293,7 @@ int usb_driver_claim_interface(struct us
 	/* if interface was already added, bind now; else let
 	 * the future device_add() bind it, bypassing probe()
 	 */
-	if (!klist_node_attached (&dev->knode_bus))
+	if (klist_node_attached(&dev->knode_bus))
 		device_bind_driver(dev);
 
 	return 0;

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/