[PATCH] musb: Fix bad call to kfree() in musb_free

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


Commit 622859634a663c5e55d0e2a2cdbb55ac058d97b3 removed a bunch of
#ifdefs from the musb code, including this change:

    @@ -1901,11 +1844,7 @@ static void musb_free(struct musb *musb)
                    dma_controller_destroy(c);
            }

    -#ifdef CONFIG_USB_MUSB_HDRC_HCD
    -       usb_put_hcd(musb_to_hcd(musb));
    -#else
            kfree(musb);
    -#endif
     }

     /*

Since musb comes from struct usb_hcd's hcd_priv, which is allocated on
the end of that struct, kfree'ing it is not going to work.  Replace
kfree(musb) with usb_put_hcd(musb_to_hcd(musb)), which appears to be
the right thing to do here.

Signed-off-by: Brian Downing <bdowning@xxxxxxxxx>
---
    Note that this patch is not sufficient to make musb device removal
    work, though it helps.  The way that resources are passed between
    the glue and core drivers does not seem to be okay; since they
    both acquire the same resources, when they get inserted into
    the resource tree what actually winds up happening is that the
    musb core's resources become the parent of the glue driver's.
    When platform_device_del'ing the musb core (which happens first) it
    winds up orphaning the glue driver's resources.  With kernel memory
    debugging on, you can see the glue driver's resource releasing hit
    upon a 0x6b6b6b6b pointer.

    I have not figured out a way to fix this resource problem that
    wouldn't be incredibly intrusive (modifying all glue drivers and all
    devices that create musb devices), but I managed to locally kludge
    around it for my purposes in the glue driver by explicitly releasing
    pdev->resource[0] before platform_device_add'ing the musb core,
    then re-inserting it after deleting the core.  Nasty!

    In case anyone's wondering, the reason I care about removing musb
    devices is that my board, using an AM1705 (a da8xx-based chip),
    appears to have a hardware problem wherein inserting some particular
    USB devices will occasionally cause the DRVVBUS register from the
    controller to go low, like it thinks it wants to be a device instead
    of a host.  (I have the PHY configured to force being a host; the
    AM1705 is missing a bunch of USB pins, including the ID and DRVVBUS
    pins, and I had to hack in some code driving a GPIO for DRVVBUS based
    on the above register.)  This situation appears to be unrecoverable
    except by resetting the controller, and removing and re-adding the
    device is a quick and reliable way of doing so.

    I am pretty confident in the nasty-hardware nature of the above bug
    because adding an six foot extension cable (not a hub!) makes one
    of my fail-one-in-ten-times-or-so devices work a lot better!

 drivers/usb/musb/musb_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 26f1bef..cac54f7 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1862,7 +1862,7 @@ static void musb_free(struct musb *musb)
 		dma_controller_destroy(c);
 	}
 
-	kfree(musb);
+	usb_put_hcd(musb_to_hcd(musb));
 }
 
 /*
-- 
1.7.11.4

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


B and H Foto and Electronics Corp.

[Linux Media]     [Video for Linux]     [Linux Input]     [Linux Audio Users]     [Photo]     [Yosemite News]    [Yosemite Photos]    [Free Online Dating]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]     [More Archives]

Add to Google Powered by Linux