On Wed, 14 Mar 2012, Greg KH wrote: > 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. Even on ACPI systems, most host controllers are not able to power off individual ports. Alan Stern -- 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