Re: [linux-usb-devel] Re: [OOPS, usbcore, releaseintf] 2.6.0-test10-mm1

From: Alan Stern (stern_at_rowland.harvard.edu)
Date: 12/12/03

  • Next message: Jesse Allen: "Re: Working nforce2, was Re: Fixes for nforce2 hard lockup, apic, io-apic, udma133 covered" 
    Date:	Fri, 12 Dec 2003 14:17:04 -0500 (EST)
To: David Brownell <david-b@pacbell.net>

    On Fri, 12 Dec 2003, David Brownell wrote:

    > Alan Stern wrote:
    >
    > > 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
    >
    > I'd split step 4 into "4a" (device descriptors) and "4b"
    > (config descriptors) ... and then re-factor so 1..4a is
    > the same code as normal khubd enumeration. That's what
    > I was looking at a while back. If you like, I'll finish
    > that and forward.

    Sure. Although depending how you do it, step 3 might be different (reuse
    the old address vs. assign a new address). Also the failure paths will be
    different. But that could all be handled with proper refactoring.

    I intended to share common code as much as possible. Since you've already
    got part of that (almost) written, I'll be happy to use your work.

    > That would also reduce the length of time the address0_sem
    > is held,

    It would? How so?

    > eliminating a deadlock when a driver probe() from
    > khubd calls "physical" reset_device() after firmware update.
    >
    > You'll notice that today's "physical reset" codepath doesn't
    > work the same way as the normal "just connected" reset. Up
    > through step (4a) there's no point to that -- it's all just
    > potential bugginess, there's no good reason I can see to
    > have those codepaths do the same thing differently.

    Agreed.

    > I think that ALL errors in that reset path should be handled
    > the same way: fail the reset, mark the device as gone, hand
    > the device to some task context ... and in that task context,
    > disconnect all the drivers, clean up sysfs, and re-enumerate
    > the device. (Without dropping power to the port; we don't
    > want to need to re-download any firmware.) Maybe there
    > should be exceptiona if the old state wasn't CONFIGURED.
    >
    > The notion of a device that's "partially reset" sounds like
    > bugs waiting to happen.

    Your choice makes error handling easier. And failure to restore an
    altsetting is a pathological case anyhow, so it's not worth worrying
    about.

    Alan Stern

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Jesse Allen: "Re: Working nforce2, was Re: Fixes for nforce2 hard lockup, apic, io-apic, udma133 covered"

    Relevant Pages