All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.