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 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.