On Wed, Mar 05, 2003 at 01:01:27PM -0800, David Brownell wrote:
> Greg KH wrote:
> >On Fri, Feb 28, 2003 at 02:46:45PM -0800, David Brownell wrote:
> >
> >>
> >>+/* the chapter 9 device states */
> >>+
> >>+enum usb_device_state {
> >>+ USB_STATE_ATTACHED = 0, /* "only" attached */
> >>+ USB_STATE_POWERED,
> >>+ USB_STATE_DEFAULT, /* limited function */
> >>+ USB_STATE_ADDRESS,
> >>+ USB_STATE_CONFIGURED, /* most functions */
> >>+ USB_STATE_SUSPENDED
> >>+};
> >
> >
> >Hm, if you read Table 9-1, the states can not be represented as a enum,
> >but need to be a bitmask (you can be attached, powered, and suspended at
> >the same time.) We've lived until now without these states, what does
> >it buy us to add them now?
>
> Actually if you go by Figure 9-1 instead, it's clearer: SUSPENDED
> is actually four different states, labeled as one! Likely so that
> the explanations (packaged in Table 9-1) all fit onto the next page.
> All the other states have reasonably clean explanations.
Ugh, I hate Figure 9-1 too :)
> But the host side can't track SUSPENDED reasonably anyway, and does
> not need to. It's the other states that are interesting. I agree
> that if we wanted to do anything with SUSPENDED it'd need thought.
Hm, I thought that if you suspend a device, that the host knows about
it. But it's been a long time since I had to worry about device states,
when writing USB firmware. All I remember is having long arguments with
people about the whole SUSPENDED thing, and in the end, I don't think
anyone even uses it...
> Why add them now? So that we can finally start finding/fixing
> some of the wierdness in the reconfig/reset/enumeration paths,
> making some of the "hidden in code flow" rules more concrete.
> Plus, no point in making gadget side code have its on versions
> of these constants.
Ok, I'll buy that.
> >>+ /* mark the device as inactive, so any further urb submissions for
> >>+ * this device will fail. "attached" is the initial state for usb,
> >>+ * it includes "not attached" (no device signaling).
> >>+ */
> >>+ dev->state = USB_STATE_ATTACHED;
> >>+
> >
> >
> >No, that's just crazy. We can't say the device is attached, as it is
> >plainly gone from the system. Either make a new state, or just live
> >without the state issues, and leave the present flag. Don't overload
> >the attached state for two different meanings.
>
> I was exactly following the USB spec here. RMK added a nonstandard
> state called NOTATTACHED ... IMO a better fix would be to just rename
> rename the state, that's what makes everyone (me too!) scratch their
> heads. USB_STATE_INITIAL or USB_STATE_INACTIVE would be clearer.
NOTATTACHED makes sense to me.
> That one really is just one state ... it's just badly named because
> whoever wrote that bit of the spec was trying to be too clever.
No, the spec doesn't say that ATTACHED is when the device is removed
from the system. Section 9.1.1.1 says:
The state of a USB device when it is detached from the USB is
not defined by this specification.
So I say we add NOTATTACHED, as we do care about that state.
thanks,
greg k-h
-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
for complex code. Debugging C/C++ programs can leave you feeling lost and
disoriented. TotalView can help you find your way. Available on major UNIX
and Linux platforms. Try it free. www.etnus.com
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
