Stavros Markou wrote:
I haev some questions concerning usb_physical_reset_device :
* Why isn't this function exported like usb_reset_device is ?
The fourth patch of that short series of mine exports it,
but renames it "__usb_reset_device" to match most other
locked/unlocked call pairs in Linux.
Hi,
I 've decided to change my approach to the reset of the device but I
haev some questions concerning usb_physical_reset_device :
* Why isn't this function exported like usb_reset_device is ?
* Why does the use of the semaphore locks kernel inside this
function before the usb_set_ad
On Fri, 16 Jan 2004, Stavros Markou wrote:
> Alan Stern wrote:
>
> >I took a quick look at your file. Making reset_device() call
> >destroy_configuration() and get_configuration() like you do is very
> >unsafe. No wonder you're getting kernel panics!
> >
> >
> >
> destroy_configuration and
Alan Stern wrote:
On Thu, 15 Jan 2004, Stavros Markou wrote:
First of all, I want to thank you and Alan for your help. Second for the
drivers I am developing and In order to be independent from a kernel 's
usb_reset_device (since it doesn't work for the moment and the users of
the driver do
Stavros, what patches are you running with? __usb_reset_device
name suggests there are some.
...
I posted a disconnect patch a while back, which included that
re-name, and later submitted a tweaked/fixed version in four
different segments. If you're using either of those, I hope
it's the latter!
On Thu, 15 Jan 2004, Stavros Markou wrote:
> First of all, I want to thank you and Alan for your help. Second for the
> drivers I am developing and In order to be independent from a kernel 's
> usb_reset_device (since it doesn't work for the moment and the users of
> the driver don't want to me
Sorry, I forgot to send the file :-) .
Stavros Markou.
Original Message
Subject: Re: [linux-usb-devel] usb_disconnect
Date: Thu, 15 Jan 2004 13:34:43 +0200
From: Stavros Markou <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: David Brownell <[EMAIL PROTECTED]&g
David Brownell wrote:
Stavros Markou wrote:
Disconnect is called when I unplug the wlan card. In the case of a
dataflash device when device_del is called dev->parent is not NULL
but in the case of eeprom device dev->parent is NULL. My opinion is that
Hmm, it might be interesting to compare du
Stavros Markou wrote:
Disconnect is called when I unplug the wlan card. In the case of a
dataflash device when device_del is called dev->parent is not NULL
but in the case of eeprom device dev->parent is NULL. My opinion is that
Hmm, it might be interesting to compare dump_stack() output
at thos
On Wed, 14 Jan 2004, Stavros Markou wrote:
> Alan Stern wrote:
>
> >Do you know why usb_disconnect() is getting called at all? Is it
> >happening inside your call to usb_reset_device()? Or is it happening
> >sometime later? Can you post the stack trace from your system panic?
> >
> >
> >
> D
Alan Stern wrote:
(Please CC: these messages to the USB development list in addition to
sending directly to me.)
On Wed, 14 Jan 2004, Stavros Markou wrote:
Alan Stern wrote:
On Tue, 13 Jan 2004, Stavros Markou wrote:
I am using that patch but now I am facing problems during d
(Please CC: these messages to the USB development list in addition to
sending directly to me.)
On Wed, 14 Jan 2004, Stavros Markou wrote:
> Alan Stern wrote:
>
> >On Tue, 13 Jan 2004, Stavros Markou wrote:
> >
> >
> >
> >>I am using that patch but now I am facing problems during disconnect
>
On Tue, 13 Jan 2004, Stavros Markou wrote:
> I am using that patch but now I am facing problems during disconnect
> because inside usb_disable_device after device_del I get a crash.
That sounds like something new. Can you post the details of what happens
when the crash occurs?
Alan Stern
-
On Mon, 12 Jan 2004, Stavros Markou wrote:
> Hi,
>
> By trying to deregister my driver from the usb subsystem I 've
> discovered that in usb_disconnect at drivers/usb/core/usb.c file :
>
> for (i = 0; i < USB_MAXCHILDREN; i++) {
>struct usb_device **child = dev->children + i;
>
Hi,
By trying to deregister my driver from the usb subsystem I 've
discovered that in usb_disconnect at drivers/usb/core/usb.c file :
for (i = 0; i < USB_MAXCHILDREN; i++) {
struct usb_device **child = dev->children + i;
if (*child)
usb_disconnect(child);
}
*child
On Thu, 8 Jan 2004, David Brownell wrote:
> Oliver Neukum wrote:
> >
> > Yes, that is true. But, maybe I am dense, but why can't this be done
> > by making state atomic or protect it by a spinlock?
>
> Not dense ... but you do seem to have overlooked the (earlier) part
> of that note which said:
Oliver Neukum wrote:
I'd describe it a bit differently: it ensures that the first phase of
disconnection (preventing new URB submissions) completes, for any/all
devices, before anything needs to block for the second or third phases
(which can take an arbitrarily long time because they need dev->se
> > see, is that it would let drivers know ASAP when a device had been
> > disconnected and it would tell the core to stop accepting URBs for that
> > device. Is that sufficient justification?
>
> I'd describe it a bit differently: it ensures that the first phase of
> disconnection (preventing
Alan Stern wrote:
On Thu, 8 Jan 2004, David Brownell wrote:
Why shouldn't it be possible for the hub code to sort that stuff
directly? Logically it's just setting a flag. Maybe dev->state
should be protected by some lock, but certainly it's easy to have
a bit that can record the disconnect even
On Thu, 8 Jan 2004, David Brownell wrote:
> >>Why shouldn't it be possible for the hub code to sort that stuff
> >>directly? Logically it's just setting a flag. Maybe dev->state
> >>should be protected by some lock, but certainly it's easy to have
> >>a bit that can record the disconnect even if
Alan Stern wrote:
I'm recombining the different parts of this thread, since things seem to
be winding down.
On Wed, 7 Jan 2004, David Brownell wrote:
Why shouldn't it be possible for the hub code to sort that stuff
directly? Logically it's just setting a flag. Maybe dev->state
should be prote
Am Donnerstag, 8. Januar 2004 16:47 schrieb Alan Stern:
> I'm recombining the different parts of this thread, since things seem to
> be winding down.
>
>
> On Wed, 7 Jan 2004, David Brownell wrote:
>
> > Why shouldn't it be possible for the hub code to sort that stuff
> > directly? Logically i
I'm recombining the different parts of this thread, since things seem to
be winding down.
On Wed, 7 Jan 2004, David Brownell wrote:
> Why shouldn't it be possible for the hub code to sort that stuff
> directly? Logically it's just setting a flag. Maybe dev->state
> should be protected by some
Alan Stern wrote:
On Mon, 5 Jan 2004, David Brownell wrote:
A hub doesn't have any state that it needs to preserve across a reset, or
at least none that can't be reconstructed after the reset. Since the
reset will automatically disconnect all downstream devices, we not only
don't want to save th
Seems to me there should really be two usb_disconnect() calls,
both of which feed disconect events to khubd. One of the calls
would come internally, from hub status transfer processing.
It's currently using the same API as the other entry point...
The other entry point would be for the HCD layer,
As soon as you mark the device as USB_STATE_NOTATTACHED, there
will be no more retries ... completions happen at whatever rate
protocol timeouts kick in, but from then on there's no way to
start new I/O. Like a car running out of gas, with no hills.
Ah, but devices aren't marked as USB_STATE_NO
Oliver Neukum wrote:
This would permit an attractive concurrency in handling unplug events.
Concurrency is not attractive, unless performance is an issue.
It is just a source of problems.
Well, the real world is concurrent, so the problems are there
regardless of whether the software is geared
On Wed, 7 Jan 2004, Oliver Neukum wrote:
> > The hooks themselves are trivial; it's what the device drivers will do
> > with them that's hard! The driver has to know what to do about incoming
> > requests while the device is unavailable, it has to be prepared to find
> > that the device ends u
Am Dienstag, 6. Januar 2004 16:59 schrieben Sie:
> Oliver, I like your messages. You always make me stop and think again. :-)
>
> When starting this thread, I had in mind some fairly small changes that
> would easily go into the 2.6 kernel series. But the kind of thing you and
> David are sugg
Oliver, I like your messages. You always make me stop and think again. :-)
When starting this thread, I had in mind some fairly small changes that
would easily go into the 2.6 kernel series. But the kind of thing you and
David are suggesting would be much larger, affecting most of the USB
dri
On Mon, 5 Jan 2004, Alan Stern wrote:
> The best way to prevent that from becoming a problem is for
> usb_disconnect() to insure the hub isn't on the event list to begin with.
> And the best way to insure _that_ is to unbind the hub driver.
In fact, this isn't such a big change as one might th
Am Dienstag, 6. Januar 2004 00:06 schrieb Alan Stern:
> On Mon, 5 Jan 2004, David Brownell wrote:
>
> > Resetting a hub also resets devices on downstream ports ...
> > including the DVD you may have been burning! That's
> > not something that seems safe to try automatically on
> > all kinds of d
On Mon, 5 Jan 2004, David Brownell wrote:
> I suppose having a reset() method somewhere would be right ... the
> virtual root hub code (in the hcd glue) would implement it one way,
> and the current hub_reset() logic would handle for non-root hubs.
>
> That could get used in three cases: (i) pan
On Mon, 5 Jan 2004, David Brownell wrote:
> > I'm not sure what you mean here. Why do you expect I/O on child devices
> > to start quiescing quickly? More likely you'll see a flurry of error
> > notifications and retries. Eventually things will die down, but you
>
> As soon as you mark the
On Mon, 5 Jan 2004, David Brownell wrote:
> > A hub doesn't have any state that it needs to preserve across a reset, or
> > at least none that can't be reconstructed after the reset. Since the
> > reset will automatically disconnect all downstream devices, we not only
> > don't want to save the c
Resetting a hub also resets devices on downstream ports ...
including the DVD you may have been burning! ...
I'm not sure how often that special case code has been used;
I don't recall noticing it happen (Maybe that's because
it's reporting with KERN_DEBUG. It should use dev_err.)
Maybe it
Responses here on two points: (a) quiescing, (b) driver.devices list
Yes, that's a good way to allow concurrency: as soon as a device
is marked "dead", take it out of the tree (sysfs would _maybe_ not
show it any more) and queue it someplace for graceful shutdown.
Whether or not that shutdown p
[ mostly relating to root hub reset processing ]
One of those cases is in hub_reset(), which I mentioned above. The others
are rather analogous although different in detail; they occur when a host
controller fails -- everything below the root hub is disconnected but the
root hub remains. In a wa
On Mon, 5 Jan 2004, David Brownell wrote:
> Resetting a hub also resets devices on downstream ports ...
> including the DVD you may have been burning! That's
> not something that seems safe to try automatically on
> all kinds of devices. For mice -- probably safe.
Yep, it's a dangerous thing t
Alan Stern wrote:
This ties in with the earlier part of this thread. Managing
malfunctioning hubs is an important aspect of maintaining the topology of
the USB bus. Right now, hub.c contains special-case code to reset a hub
for error-recovery. It ought to be possible to reuse that code for the
On Fri, 2 Jan 2004, David Brownell wrote:
> > For error recovery. If an attempt to disable the port fails, we can't
> > simply leave things as they stand -- there will be an unaddressed device
> > attached to the bus. It will be necessary to disconnect the entire hub to
> > avoid problems. A
Am Freitag, 2. Januar 2004 18:52 schrieb David Brownell:
> Oliver Neukum wrote:
>
> > - in error recovery by disabling ports we should (currently don't - but
> > that's a bug) go _up_ the tree.
>
> Why would that be? If code has a valid lock on a hub, to disable
> or reset a port on that hub,
- in error recovery by disabling ports we should (currently don't - but
that's a bug) go _up_ the tree.
Why would that be? If code has a valid lock on a hub, to disable
or reset a port on that hub, why would it get a lock on the
parent of that hub?
For error recovery. If an attempt to disable
On Fri, 2 Jan 2004, David Brownell wrote:
> Oliver Neukum wrote:
>
> > - in error recovery by disabling ports we should (currently don't - but
> > that's a bug) go _up_ the tree.
>
> Why would that be? If code has a valid lock on a hub, to disable
> or reset a port on that hub, why would it g
On Fri, 2 Jan 2004, Oliver Neukum wrote:
> Wasn't the driver model supposed to handle parent-children relations?
Indeed. That's an area where the driver model has not been fully
adopted into the USB driver framework.
> Very well, but I would still suggest a single semaphore (rw if you will)
>
Oliver Neukum wrote:
- in error recovery by disabling ports we should (currently don't - but
that's a bug) go _up_ the tree.
Why would that be? If code has a valid lock on a hub, to disable
or reset a port on that hub, why would it get a lock on the
parent of that hub?
- Dave
-
Alan Stern wrote:
On Thu, 1 Jan 2004, David Brownell wrote:
How about a lock tree?
I was playing around with a simpler idea... Have the core notify khubd
whenever it's about to remove all the children of a hub. Khubd guarantees
that after returning from the notification it will not access tha
Oliver Neukum wrote:
That way you can do things like adding devices on one hub while removing
them from another one -- concurrently.
Obviously you could do such a thing, but where is the benefit? Contention
is not an issue here. The simplest solution seems best to me.
Contention can be an issu
Am Freitag, 2. Januar 2004 05:05 schrieb Alan Stern:
> On Thu, 1 Jan 2004, Oliver Neukum wrote:
>
> > As this situations involve devices being added or removed, don't you need
> > the subsystem rw-semaphore anyway?
>
> No; the subsystem rw-semaphore is used by the driver model core when
> driver-
> That way you can do things like adding devices on one hub while removing
> them from another one -- concurrently.
Obviously you could do such a thing, but where is the benefit? Contention
is not an issue here. The simplest solution seems best to me.
Regards
Oliver
-
On Thu, 1 Jan 2004, David Brownell wrote:
> How about a lock tree?
>
> Each interior node (hub) has a lock (dev->serialize?) and they're acquired
> from root to leaf. Once you have a node's lock, you can release the parent
> lock ... to allow more parallelism. When you're done updating the chil
On Thu, 1 Jan 2004, Oliver Neukum wrote:
> As this situations involve devices being added or removed, don't you need
> the subsystem rw-semaphore anyway?
No; the subsystem rw-semaphore is used by the driver model core when
driver-model struct device's are added or removed. It is not held while
Alan Stern wrote:
Clearly some sort of locking protection is needed. The question is, what
sort? The simplest approach is to add a semaphore or spinlock protecting
the children[] arrays. But given that the exceptional accesses all occur
in situations that involve disconnecting all the devices on
> Furthermore, there are problems the simple approach doesn't solve. For
> example, consider what happens when rmmod of an HCD is recursively
> removing all the devices belong the root hub and is working its way
> through the children[] array of some intermediate hub, removing the
> entries one b
Somewhat surprisingly, the usbdev->children[] array isn't protected by any
sort of lock. It's used in three ways: recording new devices as they are
detected by the upstream hub, removing devices during disconnect
processing, and error recovery in the hub driver. Under normal conditions
all these
55 matches
Mail list logo
