On Thu, 24 Oct 2013, Dan Williams wrote:
> Summary:
> Address the following issues for port power control:
> 1/ Port power policy needs 'connector' awareness.
> 2/ Reliable port power control requires coordination with khubd.
> 3/ Userspace needs full control, but also help coordinating port
> power policy.
>
> Even with these changes port power control still defaults to disabled
> (ports are always on). This is 3.14 material.
I find these descriptions rather unclear...
> Details:
> 1/ Port power policy needs 'connector' awareness.
>
> It is a recipe for unintended device disconnects to turn off a
> port while leaving its peer active.
"It is a recipe" -- what is "it"? Do you mean that under the current
implementation, an unintended device disconnect turns off a port while
leaving the port's peer turned on? Or do you mean that this series of
patches creates a mechanism for doing this?
Which disconnects count as "unintended"?
What is a port's "peer"?
> The attached device, provided
> it is not a hub may, switch from the USB3 connection to USB2.
Are you still talking about unintended disconnects? If you are, how
can there be an attached device if it has just disconnected? Or are
you referring to a device attached to the port's peer (whatever that
is)?
Note that most USB-3 devices are not allowed to connect to the both
USB-3 and USB-2 buses at the same time. Hubs are exceptions; they are
required to do so (and consequently each USB-3 hub appears to the
system as two separate and unrelated hubs; one that is USB-3 and one
that is USB-2).
> Introduce a 'connector' object to track ports from different hcds
> (for example the two hcds provided by XHCI).
Exactly what ports will these "connectors" track? The USB-2 and USB-3
logical ports that share the same physical port on a USB-3 hub?
> A 'connector' is
> distinct from 'companion' ports which share the same data lines
> across multiple hcds.
Why treat "companion" ports differently?
> Port-connector membership data comes from
> platorm firmware.
What about port-connector membership data for ports on external hubs?
They aren't described by platform firmware.
> 2/ Reliable port power control requires coordination with khubd.
>
> The existing implementation makes attempts to mitigate the damage of
> khubd running in the middle of a port power control event, but
> makes no guarantees.
Sure it does. What damage are you talking about?
> We need to support both suspending hubs with
> live ports (to receive wakeup events) and fully powering down the
> port when userspace policy allows.
Don't we support this already?
> 3/ Userspace needs full control, but also help coordinating port
> power policy.
>
> Augment the existing controls portX/power/pm_qos_no_power_off and
> portX/power/control with connector awareness (i.e. propagate control
> settings across ports in a connector), but also add policies based
> on the connector type ('hotplug' ports never power down as compared
> to 'hardwired').
Isn't this already implemented, at least in part? I thought we
treated hotpluggable ports differently from hardwired ports.
> Even with these changes port power control still defaults to on.
>
> When enabled (pm_qos_no_power_off=0) it tries to do the right thing
> for connectors and hotplug capable ports. At all times userspace
> can override what acpi has defined (pm_qos_no_notify_flags to stop
> propagating settings to 'peers', connect_type to override whether
> the port is hotplug capable, or usbcore.noacpi to turn it all off).
It might help to put somewhere a complete description of all the
mechanisms involved in port power control, and how they interact,
together with a description of which items (and attribute files) can be
changed by userspace.
Alan Stern
--
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
