Am Wednesday 28 January 2009 22:43:21 schrieb David Brownell: > On Wednesday 28 January 2009, Alan Stern wrote: > > I've been too busy to take part in this discussion (upgrading to Fedora > > 10 was a disaster because the X server doesn't work on my machine) -- > > there hasn't even been time enough in the last few months to read > > through much of the USB 3.0 spec. So I have only a few comments to > > add... > > Which is why I encouraged a high-level description of the issues > first. I don't think many folk have had a chance to read it. Hi Sarah, OK, having read it seems to me that some changes to common APIs are needed. I'll just list the issues in the order I've noticed them, not ranked by impact. That is apart from the burst support. 1. warm and hot resets We now have two kinds of resets and need to add a "warmth" parameter to usb_reset_device() 2. remote wakeup operates on the function level We need to have true functions that request/release remote wakeup with counters per function that request/release remote wakeup immediately. 3. Section 9.2.5.2 I read this as saying that the device is allowed to forget almost all internal state when going into U3 (==suspend). Sarah? 4. U1/U2 handling We have 3 depths of sleep compared to the binary suspend/active distinction. U1/2 affects only the link, not the device. They can be initiated both by the device and the host(hub) If we want to use this we need some support: - We need to make sure the additional latency does not conflict with periodic transfers - We need timeout values for all interfaces. From this we should compute the longest timeout, or if a driver forbids U1/U2 disable them - IMHO the default value should be $FF that is we allow devices to initiate U1/2 but don't propose to enter it ourselves, unless periodic transfers require U1/2 be disabled - This might be hooked into latency/power user space interfaces 5. Functions Section 9.6.4 USB 3.0 introduces functions as an additional level between device and interfaces. In fact section 9.6.4 can be read as recommending function level drivers in addition to interface level drivers. Sarah, how do you read this? As some functionality in powermanagement resides in functions, we need to have a kernel representation of them. Particularily we need to register which interfaces belong to a function and autosuspend must be trained to go at functions. That means interface association descriptors must be evaluated. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
