On 2012年11月12日 10:43, Alan Stern wrote: > On Mon, 12 Nov 2012, Lan Tianyu wrote: > >>>> This will consume more power than suspend it >>>> agian. >>> >>> No it won't, because the device will suspend itself after 3 ms. >> But the premise is "they see a constant Idle state on their upstream >> facing bus lines for more than 3.0 ms", that means the port's suspend >> feature should be set to prevent all the bus activity(e.g sof), right? > > No, it only means that the port doesn't transmit packets. This could > be because the port's suspend feature is set, or it could be because > the port's enable feature is clear. > >> Now I have another concern that the device will maintain address 0 after >> repower and not reset-resume. What happen if another device was plugged in? > > If the port isn't enabled, it doesn't matter. Hi Alan: I find another problem. We clear PORT_POWER feature in the port's runtime suspend callback. But when port's pm qos flags is updating, pm core will call pm_runtime_get_sync/put(dev). This will cause the PORT_POWER feature to be set and cleared. The result always is "power off" after port's pm qos flags being changed. > > Alan Stern > -- Best regards Tianyu Lan -- 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
