On Wed, Mar 14, 2012 at 12:48:11PM +0000, Matthew Garrett wrote: > On Wed, Mar 14, 2012 at 09:20:44AM +0800, Lan Tianyu wrote: > > On 2012年03月13日 05:45, Matthew Garrett wrote: > > >Built-in USB devices will typically have a representation in the system > > >ACPI tables. Add support for binding the two together so the USB code can > > >make use of the associated methods. > > hi Matthew: > > acpi glue framework only can cover situation that the port has been > > connected with some device. so without device, no acpi handle can be used to > > access "UPC" and "PLD". > > Whether the usb port is user-visible or not is also useful when there > > is no device. For example, if it is known that the usb port is not user-visible > > and connectable. The usb hub port can be power-off. > > So usb/acpi binding should consider those usb ports without plugging device. > > Does this make sense? :) > > I agree that this woud be useful, but right now we don't have port > objects so there's nowhere to expose this. Greg, do you have any > feelings about how this coud be handled? If you wanted to do something like this, you are right, you would need to create a "port" device and put it on every hub. Odds are that's probably not worth it as you will be adding more indirection on every USB device, yet only ACPI based systems would be able to do anything with them. Is there really a power savings to turn off a port if nothing is present in it? If so, how do we know to wake it up? What if we really wanted it on just to "charge" something, and it never was showing up as a real device? Messing with that could get very tricky very quickly. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
