On Sat, 1 Apr 2006, Russell King wrote:
> On Thu, Mar 30, 2006 at 03:45:50PM -0500, Alan Stern wrote:
> > I recently tried running the dummy_hcd driver for the first time in a
> > while, and it crashed when the gadget driver was unloaded. It turns out
> > this was because the gadget's embedded struct device is registered without
> > a bus, which triggers an oops when the device's driver is unbound. The
> > oops could be fixed by doing this:
>
> Can you provide the oops itself please?
No, I don't have it any more. But I can tell you exactly where the oops
occurred. In __device_release_driver() (in drivers/base/dd.c), this line
you added:
if (dev->bus->remove)
crashed because dev->bus was NULL. My patch changes the line to:
if (dev->bus && dev->bus->remove)
Any objection to that?
> > Part of the problem here is that most of the USB controllers are platform
> > devices and so belong on the platform bus.
>
> You're making a connection where no such connection exists. Devices
> are only part of the platform bus if they explicitly want to be (in
> much the same way that devices are only part of the PCI bus if they
> explicitly set dev->bus to be the PCI bus.)
I think you have misunderstood my point. Yes, devices are part of the
platform bus only if they explicitly want to be. My point was that even
though they _do_ want to be on the platform bus, in this situation they
_can't_ because they are forced to register a struct device, not a struct
platform_device. The choice is not up to the driver; it is determined by
the USB Gadget framework. (See the definition of struct usb_gadget in
include/linux/usb_gadget.h -- there's an embedded struct device, not an
embedded struct platform_device.)
> > But struct usb_gadget contains an embedded struct device, not an embedded
> > struct platform_device... so the gadget _can't_ be registered on its
> > parent's bus.
>
> From what I can see, the embedded device does not belong to any bus at
> all since dev->bus is NULL. Hence, I don't think it's the embedded
> struct device which is causing the problem here.
>
> It would be good to see the entire oops to see what's going on.
Yes, the device did not belong to any bus. Hence the unguarded reference
to dev->bus->remove caused the oops. If it's legal for devices not to
belong to a bus, then my patch should be applied to guard the reference.
If it's not legal then the Gadget framework needs to be changed.
Alan Stern
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
