From: Alan Stern <stern@rowland.harvard.edu>
To: Duncan Sands <baldrick@free.fr>
Cc: Kernel development list <linux-kernel@vger.kernel.org>,
USB development list <linux-usb-devel@lists.sourceforge.net>
Subject: Re: [linux-usb-devel] Re: [OOPS, usbcore, releaseintf] 2.6.0-test10-mm1
Date: Fri, 12 Dec 2003 11:18:19 -0500 (EST) [thread overview]
Message-ID: <Pine.LNX.4.44L0.0312121047590.1297-100000@ida.rowland.org> (raw)
In-Reply-To: <200312112229.04256.baldrick@free.fr>
On Thu, 11 Dec 2003, Duncan Sands wrote:
> From what Dave says, usb_reset_device shouldn't take dev->serialize (but
> accidentally does via usb_set_configuration). That seems strange to me:
> I thought the point of usbfs taking dev->serialize is to protect against the
> device settings changing, but now we have usb_reset_device that doesn't
> take dev->serialize at all - and surely it changes the device settings!
>
> With much confusion,
Maybe it will help if I explain how usb_reset_device will work in the
future.
First of all, as David has said, it does and will grab dev->serialize.
The alternate entry point (...physical...) will require the caller to
hold it already.
The routine will:
1. issue the port reset
2. make sure the device is still attached
3. assign it the same address as it had before
4. read the device and configuration descriptors
5. make sure they are equal to the old descriptor values
6. install the old configuration (if the old state was CONFIGURED)
7. select the old altsettings for each interface
If anything goes wrong with step 1, the routine simply returns an error.
If something goes wrong in steps 2-6, the routine will set a flag in the
usb_device indicating STATE_CHANGE_PENDING. Several other routines will
have to be modified to check this flag before doing anything else
(set_config, set_interface, and so on). The khubd thread will be woken up
to handle the pending state change.
If the problem arose in steps 2-4, the device will be marked for a pending
port-disable and disconnect. If it arose in step 5, the device will be
marked as changed -- a sort of logical disconnect followed by connect,
requiring enumeration and all the other usual stuff. A problem in step 6
will end up leaving the device back in the ADDRESS state.
If a problem arises in step 7, I'm not sure what to do. The driver bound
to the malfunctioning interface should be forcibly unbound. However that
might be the driver which called reset_device, so it can't be unbound
right away. Regardless, the reset_device routine will return success.
With this approach, a large part of the work in the "device changed"
pathway is pushed off to khubd. Running in a different process context,
it will be able to acquire the serialize lock, the bus rwsem, and whatever
else is needed.
In fact, I'd like to do the actual work not in khubd itself but in a
different process. Maybe a work queue, maybe just a temporary kernel
thread spawned each time it's needed by khubd. That's true for regular
connect and disconnect processing as well. The advantage of this is that
khubd itself will no longer be blocked by badly behaved drivers waiting
(or hung) in their probe/disconnect routines, so it will better be able to
concentrate on its main job of managing hubs.
I've been waiting for the code freeze to end before doing any of the real
work. Now that Greg is accepting and applying patches again, I'll get
going on this.
Alan Stern
next prev parent reply other threads:[~2003-12-12 16:18 UTC|newest]
Thread overview: 113+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-26 16:51 [kernel panic @ reboot] 2.6.0-test10-mm1 Vince
2003-11-26 17:16 ` Zwane Mwaikambo
2003-11-26 17:34 ` Vince
2003-11-26 17:35 ` Randy.Dunlap
2003-11-26 17:40 ` Zwane Mwaikambo
2003-11-26 17:54 ` Vince
2003-11-26 18:18 ` Zwane Mwaikambo
2003-11-26 23:37 ` Mike Fedyk
2003-11-26 23:41 ` Vince
2003-12-03 0:03 ` Randy.Dunlap
2003-12-03 0:31 ` Mike Fedyk
2003-12-03 0:27 ` Randy.Dunlap
2003-12-03 13:28 ` Vince
2003-12-03 19:12 ` Zwane Mwaikambo
2003-12-04 1:01 ` Vince
2003-12-04 1:34 ` Mike Fedyk
2003-12-04 4:11 ` Randy.Dunlap
2003-12-04 10:59 ` [OOPS, usbcore, releaseintf] 2.6.0-test10-mm1 Vince
2003-12-04 11:14 ` Duncan Sands
2003-12-04 16:57 ` Randy.Dunlap
2003-12-05 7:38 ` Duncan Sands
2003-12-05 10:11 ` Vince
2003-12-05 10:18 ` Duncan Sands
2003-12-05 10:34 ` Vince
2003-12-07 0:25 ` Duncan Sands
2003-12-07 21:09 ` Vince
2003-12-07 21:24 ` Duncan Sands
2003-12-07 22:24 ` Vince
2003-12-07 22:54 ` Vince
2003-12-08 10:10 ` Duncan Sands
2003-12-08 16:03 ` [linux-usb-devel] " David Brownell
2003-12-08 16:15 ` Duncan Sands
2003-12-08 16:31 ` Alan Stern
2003-12-08 17:20 ` David Brownell
2003-12-08 17:59 ` Duncan Sands
2003-12-08 18:35 ` Alan Stern
2003-12-08 19:53 ` Duncan Sands
2003-12-08 21:32 ` Alan Stern
2003-12-08 21:55 ` Duncan Sands
2003-12-08 23:09 ` Alan Stern
2003-12-09 10:23 ` Duncan Sands
2003-12-09 15:55 ` Alan Stern
2003-12-09 20:36 ` Duncan Sands
2003-12-09 10:36 ` Duncan Sands
2003-12-09 16:08 ` Alan Stern
2003-12-09 20:24 ` Duncan Sands
2003-12-09 10:49 ` Duncan Sands
2003-12-09 15:47 ` Alan Stern
2003-12-09 21:12 ` Duncan Sands
2003-12-09 21:58 ` Alan Stern
2003-12-09 22:07 ` Duncan Sands
2003-12-09 22:25 ` David Brownell
2003-12-09 22:33 ` Duncan Sands
2003-12-10 3:12 ` David Brownell
2003-12-10 3:43 ` Alan Stern
2003-12-10 13:12 ` Duncan Sands
2003-12-10 15:13 ` Alan Stern
2003-12-10 15:30 ` Greg KH
2003-12-10 16:02 ` Duncan Sands
2003-12-10 20:53 ` Greg KH
2003-12-11 8:49 ` Duncan Sands
2003-12-11 9:23 ` Greg KH
2003-12-11 9:29 ` Duncan Sands
2003-12-10 17:25 ` Alan Stern
2003-12-10 20:46 ` Greg KH
2003-12-10 21:08 ` Greg KH
2003-12-11 2:10 ` Vince
2003-12-11 6:46 ` Greg KH
2003-12-10 22:08 ` Alan Stern
2003-12-11 6:47 ` Greg KH
2003-12-10 4:31 ` Vince
2003-12-10 1:49 ` Greg KH
2003-12-10 13:22 ` Duncan Sands
2003-12-10 16:20 ` Oliver Neukum
2003-12-10 16:49 ` Duncan Sands
2003-12-10 16:58 ` Oliver Neukum
2003-12-11 9:45 ` Duncan Sands
2003-12-11 10:19 ` Oliver Neukum
2003-12-11 21:43 ` Duncan Sands
2003-12-11 22:57 ` Oliver Neukum
2003-12-11 23:30 ` Duncan Sands
2003-12-12 0:02 ` David Brownell
2003-12-10 17:34 ` David Brownell
2003-12-10 17:54 ` Duncan Sands
2003-12-10 18:19 ` Alan Stern
2003-12-11 9:36 ` Duncan Sands
2003-12-11 15:19 ` Alan Stern
2003-12-11 21:23 ` Duncan Sands
2003-12-12 15:46 ` Alan Stern
2003-12-11 21:29 ` Duncan Sands
2003-12-12 16:18 ` Alan Stern [this message]
2003-12-12 18:37 ` David Brownell
2003-12-12 19:17 ` Alan Stern
2003-12-12 19:45 ` David Brownell
2003-12-12 20:48 ` Alan Stern
2003-12-12 21:01 ` Oliver Neukum
2003-12-12 21:27 ` Alan Stern
2003-12-12 23:36 ` Oliver Neukum
2003-12-13 1:10 ` Alan Stern
2003-12-13 11:52 ` Oliver Neukum
2003-12-12 18:50 ` Oliver Neukum
2003-12-10 19:43 ` David Brownell
2003-12-11 9:21 ` Duncan Sands
2003-12-10 17:21 ` David Brownell
2003-12-11 9:42 ` Duncan Sands
2003-12-12 2:21 ` David Brownell
2003-12-12 8:47 ` Duncan Sands
2003-12-12 15:35 ` bill davidsen
2003-12-05 0:08 ` [kernel panic @ reboot] 2.6.0-test10-mm1 Zwane Mwaikambo
2003-11-27 0:59 ` [kernel panic @ reboot in usbcore] 2.6.0-test10-mm1 (culprit: modem_run) Vince
2003-11-27 3:13 ` Zwane Mwaikambo
2003-11-27 8:14 ` Vince
2003-11-27 8:11 ` Duncan Sands
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=Pine.LNX.4.44L0.0312121047590.1297-100000@ida.rowland.org \
--to=stern@rowland.harvard.edu \
--cc=baldrick@free.fr \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb-devel@lists.sourceforge.net \
/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;
as well as URLs for NNTP newsgroup(s).