From: Greg KH <greg@kroah.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: David Brownell <david-b@pacbell.net>,
Russell King <rmk@arm.linux.org.uk>,
Kernel development list <linux-kernel@vger.kernel.org>
Subject: Re: Handling devices that don't have a bus
Date: Thu, 30 Mar 2006 14:26:26 -0800 [thread overview]
Message-ID: <20060330222626.GA18633@kroah.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0603301520330.4652-100000@iolanthe.rowland.org>
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 gadgets were registered on a bus, you would expect it to be the bus of
> their parent USB device controllers. As it happens, most of the UDC
> drivers don't register their gadgets in sysfs at all. dummy_hcd and
> net2280 are exceptions. Presumably this same oops would affect net2280
> but I haven't tried it.
>
> 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 :(
> I suppose David could change things so that usb_gadget does contain a
> platform_device. But then what about the net2280, which is a PCI device
> rather than a platform device? Would it want to register its child on the
> platform bus?
>
> What's the right thing to do 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?
thanks,
greg k-h
next prev parent reply other threads:[~2006-03-31 5:45 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 [this message]
2006-04-01 9:38 ` Russell King
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=20060330222626.GA18633@kroah.com \
--to=greg@kroah.com \
--cc=david-b@pacbell.net \
--cc=linux-kernel@vger.kernel.org \
--cc=rmk@arm.linux.org.uk \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox