public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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