Re: [PATCH v2 14/14] USB: Documentation for USB port power off mechanisms

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Nov 22, 2013 at 2:46 AM, Oliver Neukum <oneukum@xxxxxxx> wrote:
> On Fri, 2013-11-22 at 01:08 -0800, Dan Williams wrote:
>> From: Lan Tianyu <tianyu.lan@xxxxxxxxx>
>>
>> Describe the mechanisms for controlling port power policy and
>> discovering the port power state.
>
>> +     power/pm_qos_no_power_off:
>> +             This writable flag is a global enable / disable for port
>> +             power management.  Once this file is set to '0' poweroff
>> +             may occur once all other constraints are met.  This
>> +             defaults to '1'.
>> +
>> +     power/control:
>> +             This file is writable and can be set to
>> +             'auto' (the default) to let the kernel power down the
>> +             device when it is idle, or 'on' to disable power
>> +             management and keep the port powered.
>
> These entries contradict one another. I think you need to rewrite
> them.

Not necessarily the best job of distinguishing the difference...

power/control:  This file is writable and enables the kernel to track
whether the device is idle or in active use when set to 'auto'.  When
set to 'on' usage is not tracked and the port remains 'active' /
powered at all time.  When set to 'auto' and the device becomes idle
it may transition to the 'suspended' state.  Once that occurs the port
may power off subject to other constraints.

power/pm_qos_no_power_off:  Once the port has become idle and
transitioned to the 'suspended' state the kernel may then turn off
power.  This flag when set to '1' prevents power off in the
'suspended' state.  When set to '0' it enables further constraints to
be checked before powering off.

>> +     connect_type:
>> +             This writable file reflects the capability of the
>> +             connection to respond to hotplug events.  It returns one
>> +             of four values 'hotplug', 'hardwired', 'not used', and
>> +             'unknown'.  The default value is populated by platform
>> +             firmware, and for all but the 'hardwired' type hotplug
>> +             support is enabled.  One can write 'hardwired' to turn
>> +             off hotplug (allow the port to power down), or 'hotplug'
>> +             to keep the port powered.  The other types can not be
>> +             written to the file.
>> +
>> +             Details on the connection type:
>> +             "hotplug" refers to a port on the outside of a laptop
>> +             which is visible and connectable.
>> +
>> +             "hardwired" refers to a port that is not visible but
>> +             connectable. Examples are internal ports for USB
>> +             bluetooth that can be disconnected via an external
>> +             switch or a port with a hardwired USB camera.
>
> But those are different cases. The bluetooth module will react to rfkill
> with a hotplug. The camera won't. The examples are poorly chosen.
>

Agreed. The rfkill implementation would need to arrange for the port
to be powered.  I'll rework this.

>> +
>> +             "not used" refers to internal port that will never have
>> +             a device connected to it.  These may be empty internal
>> +             ports, or ports that are not physically
>> +             exposed on a platform.
>> +
>> +             "unknown" means platform does not provide information
>> +             for this port.
>
>         Regards
>                 Oliver

Thanks for taking a look.
--
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




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux