From: Russell King <rmk+lkml@arm.linux.org.uk>
To: Greg KH <greg@kroah.com>
Cc: Alan Stern <stern@rowland.harvard.edu>,
David Brownell <david-b@pacbell.net>,
Kernel development list <linux-kernel@vger.kernel.org>
Subject: Re: Handling devices that don't have a bus
Date: Sat, 1 Apr 2006 10:38:26 +0100 [thread overview]
Message-ID: <20060401093826.GA2636@flint.arm.linux.org.uk> (raw)
In-Reply-To: <20060330222626.GA18633@kroah.com>
On Thu, Mar 30, 2006 at 02:26:26PM -0800, Greg KH wrote:
> On Thu, Mar 30, 2006 at 03:45:50PM -0500, Alan Stern wrote:
> > Greg et al.:
> >
> > 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:
>
> Why not make the dummy gadget a platform device? That should keep this
> from happening, right?
>
> > Index: usb-2.6/drivers/base/dd.c
> > ===================================================================
> > --- usb-2.6.orig/drivers/base/dd.c
> > +++ usb-2.6/drivers/base/dd.c
> > @@ -209,7 +209,7 @@ static void __device_release_driver(stru
> > sysfs_remove_link(&dev->kobj, "driver");
> > klist_remove(&dev->knode_driver);
> >
> > - if (dev->bus->remove)
> > + if (dev->bus && dev->bus->remove)
> > dev->bus->remove(dev);
> > else if (drv->remove)
> > drv->remove(dev);
> >
> > but I'm not so sure this is the right approach. (Russell wrote the line
> > that this would change; that's why I have CC'ed him.) Is the current
> > policy that every device is supposed to belong to a bus?
If a device belongs to a bus, dev->bus will be non-NULL. I don't see
what "every device is supposed to belong to a bus" fits with the problem.
> > Part of the problem here is that most of the USB controllers are platform
> > devices and so belong on the platform bus. That's true of dummy_hcd.
> > 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.
>
> ah, ick :(
If the device's dev->bus is NULL, we don't register it on the parents
bus, but we do register it in the device tree as a child of the parent
device.
I think there's confusion here.
> I think your patch is the right thing. Care to resend it with a proper
> Signed-off-by: line so I can apply it?
First lets sort out the confusion before applying any patches.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
next prev parent reply other threads:[~2006-04-01 9:38 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-30 20:45 Handling devices that don't have a bus Alan Stern
2006-03-30 21:28 ` David Brownell
2006-03-30 22:26 ` Greg KH
2006-04-01 9:38 ` Russell King [this message]
2006-04-01 9:47 ` Russell King
2006-04-01 16:46 ` Alan Stern
2006-04-01 17:12 ` Russell King
2006-04-01 17:32 ` David Brownell
2006-04-01 20:14 ` Alan Stern
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060401093826.GA2636@flint.arm.linux.org.uk \
--to=rmk+lkml@arm.linux.org.uk \
--cc=david-b@pacbell.net \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=stern@rowland.harvard.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.