Table of Contents
This content relates to a deprecated version of Mbed
In existing Linux kernels, the Linux Device Driver Model allows a physical device to be handled by only a single driver. The PCI Express Port is a PCI-PCI Bridge device with multiple distinct services. To maintain a clean and simple solution each service may have its own software service driver. Open Control Panel Device Manager; Plug in your device; Locate Universal Serial Bus Controllers Apple Mobile Device USB Driver. It is also possible the device may show under Imaging Devices, Portable Devices, Other Devices or as an MTB USB Device. Right-click and select Update Driver Software. Click Browse my computer for driver software.
Mbed 2 is now deprecated. For the latest version please see the Mbed OS documentation.
For the latest information about Serial, please see The Windows Serial Driver.
The mbed serial port works by default on Mac and Linux, but Windows needs a driver. These instructions explain how to setup the mbed Microcontroller to use the USB serial port on Windows.
1. Download the mbed Windows serial port driver¶
Download the installer to your PC, e.g. your desktop.
2. Run the installer¶
mbed plugged in, and no explorer drive windows open, run the installer:
It will take some time (especially on Vista), and pop up a few 'unsigned driver' warnings, but after a while you should have a Serial port.
- SerialPC - Communication with a PC
- Terminals - Guide to using terminal applications
If you have multiple mbed microcontrollers, but the serial port only appears for one of them:
- Make sure you run the installer for every mbed; windows loads the driver based on the serial number, so it needs to be run for each mbed you use
If the installer fails because 'No mbed Microcontrollers were found':
- Check your mbed Microcontroller is plugged in
If the installer reports the message 'mbedWinSerial_nnnnn.exe is not a valid Win32 application':
- It is likely you are using Internet Explorer to download the installer file, which sometimes seems to only download part of the installer application for an unknown reason
- To solve this, download the installer with a different browser (Firefox, Chrome), and try again; this should solve the issue.
If the Installer appears to hang:
- Check if windows has popped-up a 'unsigned driver/permission' window; these often get hidden behind other windows with nothing to indicate so in the taskbar! Windows may be waiting for you to click 'OK'!
If you have any problems, or think this tutorial could be improved, please tell us in the Forum!
|Author:||Alan Stern <email@example.com>|
|Date:||Last-updated: February 2014|
What is Power Management?¶
Power Management (PM) is the practice of saving energy by suspendingparts of a computer system when they aren’t being used. While acomponent is
suspended it is in a nonfunctional low-power state; itmight even be turned off completely. A suspended component can be
resumed (returned to a functional full-power state) when the kernelneeds to use it. (There also are forms of PM in which components areplaced in a less functional but still usable state instead of beingsuspended; an example would be reducing the CPU’s clock rate. Thisdocument will not discuss those other forms.)
When the parts being suspended include the CPU and most of the rest ofthe system, we speak of it as a “system suspend”. When a particulardevice is turned off while the system as a whole remains running, wecall it a “dynamic suspend” (also known as a “runtime suspend” or“selective suspend”). This document concentrates mostly on howdynamic PM is implemented in the USB subsystem, although system PM iscovered to some extent (see
Documentation/power/*.txt for moreinformation about system PM).
System PM support is present only if the kernel was built with
CONFIG_HIBERNATION enabled. Dynamic PM support
for USB is present wheneverthe kernel was built with
[Historically, dynamic PM support for USB was present only if thekernel had been built with
CONFIG_USB_SUSPEND enabled (which depended on
CONFIG_PM_RUNTIME). Starting with the 3.10 kernel release, dynamic PMsupport for USB was present whenever the kernel was built with
CONFIG_PM_RUNTIME enabled. The
CONFIG_USB_SUSPEND option had beeneliminated.]
What is Remote Wakeup?¶
When a device has been suspended, it generally doesn’t resume untilthe computer tells it to. Likewise, if the entire computer has beensuspended, it generally doesn’t resume until the user tells it to, sayby pressing a power button or opening the cover.
However some devices have the capability of resuming by themselves, orasking the kernel to resume them, or even telling the entire computerto resume. This capability goes by several names such as “Wake OnLAN”; we will refer to it generically as “remote wakeup”. When adevice is enabled for remote wakeup and it is suspended, it may resumeitself (or send a request to be resumed) in response to some externalevent. Examples include a suspended keyboard resuming when a key ispressed, or a suspended USB hub resuming when a device is plugged in.
When is a USB device idle?¶
A device is idle whenever the kernel thinks it’s not busy doinganything important and thus is a candidate for being suspended. Theexact definition depends on the device’s driver; drivers are allowedto declare that a device isn’t idle even when there’s no actualcommunication taking place. (For example, a hub isn’t considered idleunless all the devices plugged into that hub are already suspended.)In addition, a device isn’t considered idle so long as a program keepsits usbfs file open, whether or not any I/O is going on.
If a USB device has no driver, its usbfs file isn’t open, and it isn’tbeing accessed through sysfs, then it definitely is idle.
Forms of dynamic PM¶
Dynamic suspends occur when the kernel decides to suspend an idledevice. This is called
autosuspend for short. In general, a devicewon’t be autosuspended unless it has been idle for some minimum periodof time, the so-called idle-delay time.
Of course, nothing the kernel does on its own initiative shouldprevent the computer or its devices from working properly. If adevice has been autosuspended and a program tries to use it, thekernel will automatically resume the device (autoresume). For thesame reason, an autosuspended device will usually have remote wakeupenabled, if the device supports remote wakeup.
It is worth mentioning that many USB drivers don’t supportautosuspend. In fact, at the time of this writing (Linux 2.6.23) theonly drivers which do support it are the hub driver, kaweth, asix,usblp, usblcd, and usb-skeleton (which doesn’t count). If anon-supporting driver is bound to a device, the device won’t beautosuspended. In effect, the kernel pretends the device is neveridle.
We can categorize power management events in two broad classes:external and internal. External events are those triggered by someagent outside the USB stack: system suspend/resume (triggered byuserspace), manual dynamic resume (also triggered by userspace), andremote wakeup (triggered by the device). Internal events are thosetriggered within the USB stack: autosuspend and autoresume. Note thatall dynamic suspend events are internal; external agents are notallowed to issue dynamic suspends.
The user interface for dynamic PM¶
The user interface for controlling dynamic PM is located in the
power/subdirectory of each USB device’s sysfs directory, that is, in
/sys/bus/usb/devices/../power/ where ”..” is the device’s ID. Therelevant attribute files are: wakeup, control, and
autosuspend_delay_ms. (There may also be a file named
level; thisfile was deprecated as of the 2.6.35 kernel and replaced by the
control file. In 2.6.38 the
autosuspend file will be deprecatedand replaced by the
autosuspend_delay_ms file. The only differenceis that the newer file expresses the delay in milliseconds whereas theolder file uses seconds. Confusingly, both files are present in 2.6.37but only
enabledor the word
disabled, and you canwrite those words to the file. The setting determineswhether or not remote wakeup will be enabled when thedevice is next suspended. (If the setting is changedwhile the device is suspended, the change won’t takeeffect until the following suspend.)
This file contains one of two words:
auto.You can write those words to the file to change thedevice’s setting.
onmeans that the device should be resumed andautosuspend is not allowed. (Of course, systemsuspends are still allowed.)
autois the normal state in which the kernel isallowed to autosuspend and autoresume the device.
(In kernels up to 2.6.32, you could also specify
suspend, meaning that the device should remainsuspended and autoresume was not allowed. Thissetting is no longer supported.)
power/autosuspend_delay_ms and writing
power/control do essentially the same thing – they both prevent thedevice from being autosuspended. Yes, this is a redundancy in theAPI.
(In 2.6.21 writing
power/autosuspend would prevent the devicefrom being autosuspended; the behavior was changed in 2.6.22. The
power/autosuspend attribute did not exist prior to 2.6.21, and the
power/level attribute did not exist prior to 2.6.22.
power/controlwas added in 2.6.34, and
power/autosuspend_delay_ms was added in2.6.37 but did not become functional until 2.6.38.)
Changing the default idle-delay time¶
The default autosuspend idle-delay time (in seconds) is controlled bya module parameter in usbcore. You can specify the value when usbcoreis loaded. For example, to set it to 5 seconds instead of 2 you woulddo:
Equivalently, you could add to a configuration file in /etc/modprobe.da line saying:
Some distributions load the usbcore module very early during the bootprocess, by means of a program or script running from an initramfsimage. To alter the parameter value you would have to rebuild thatimage.
If usbcore is compiled into the kernel rather than built as a loadablemodule, you can add:
to the kernel’s boot command line.
Finally, the parameter value can be changed while the system isrunning. If you do:
then each new USB device will have its autosuspend idle-delayinitialized to 5. (The idle-delay values for already existing deviceswill not be affected.)
Setting the initial default idle-delay to -1 will prevent anyautosuspend of any USB device. This has the benefit of allowing youthen to enable autosuspend for selected devices.
The USB specification states that all USB devices must support powermanagement. Nevertheless, the sad fact is that many devices do notsupport it very well. You can suspend them all right, but when youtry to resume them they disconnect themselves from the USB bus orthey stop working entirely. This seems to be especially prevalentamong printers and scanners, but plenty of other types of device havethe same deficiency.
For this reason, by default the kernel disables autosuspend (the
power/control attribute is initialized to
on) for all devices otherthan hubs. Hubs, at least, appear to be reasonably well-behaved inthis regard.
(In 2.6.21 and 2.6.22 this wasn’t the case. Autosuspend was enabledby default for almost all USB devices. A number of people experiencedproblems as a result.)
This means that non-hub devices won’t be autosuspended unless the useror a program explicitly enables it. As of this writing there aren’tany widespread programs which will do this; we hope that in the nearfuture device managers such as HAL will take on this addedresponsibility. In the meantime you can always carry out thenecessary operations by hand or add them to a udev script. You canalso change the idle-delay time; 2 seconds is not the best choice forevery device.
If a driver knows that its device has proper suspend/resume support,it can enable autosuspend all by itself. For example, the videodriver for a laptop’s webcam might do this (in recent kernels theydo), since these devices are rarely used and so should normally beautosuspended.
Sometimes it turns out that even when a device does work okay withautosuspend there are still problems. For example, the usbhid driver,which manages keyboards and mice, has autosuspend support. Tests witha number of keyboards show that typing on a suspended keyboard, whilecausing the keyboard to do a remote wakeup all right, will nonethelessfrequently result in lost keystrokes. Tests with mice show that someof them will issue a remote-wakeup request in response to buttonpresses but not to motion, and some in response to neither.
The kernel will not prevent you from enabling autosuspend on devicesthat can’t handle it. It is even possible in theory to damage adevice by suspending it at the wrong time. (Highly unlikely, butpossible.) Take care.
The driver interface for Power Management¶
The requirements for a USB driver to support external power managementare pretty modest; the driver need only define:
methods in its
usb_driver structure, and the
reset_resume methodis optional. The methods’ jobs are quite simple:
suspendmethod is called to warn the driver that thedevice is going to be suspended. If the driver returns anegative error code, the suspend will be aborted. Normallythe driver will return 0, in which case it must cancel alloutstanding URBs (
usb_kill_urb()) and not submit any more.
resumemethod is called to tell the driver that thedevice has been resumed and the driver can return to normaloperation. URBs may once more be submitted.
reset_resumemethod is called to tell the driver thatthe device has been resumed and it also has been reset.The driver should redo any necessary device initialization,since the device has probably lost most or all of its state(although the interfaces will be in the same altsettings asbefore the suspend).
If the device is disconnected or powered down while it is suspended,the
disconnect method will be called instead of the
reset_resume method. This is also quite likely to happen whenwaking up from hibernation, as many systems do not maintain suspendcurrent to the USB host controllers during hibernation. (It’spossible to work around the hibernation-forces-disconnect problem byusing the USB Persist facility.)
reset_resume method is used by the USB Persist facility (seeUSB device persistence during system suspend) and it can also be used under certaincircumstances when
CONFIG_USB_PERSIST is not enabled. Currently, if adevice is reset during a resume and the driver does not have a
reset_resume method, the driver won’t receive any notification aboutthe resume. Later kernels will call the driver’s
disconnect method;2.6.23 doesn’t do this.
USB drivers are bound to interfaces, so their
resumemethods get called when the interfaces are suspended or resumed. Inprinciple one might want to suspend some interfaces on a device (i.e.,force the drivers for those interface to stop all activity) withoutsuspending the other interfaces. The USB core doesn’t allow this; allinterfaces are suspended when the device itself is suspended and allinterfaces are resumed when the device is resumed. It isn’t possibleto suspend or resume some but not all of a device’s interfaces. Theclosest you can come is to unbind the interfaces’ drivers.
The driver interface for autosuspend and autoresume¶
To support autosuspend and autoresume, a driver should implement allthree of the methods listed above. In addition, a driver indicatesthat it supports autosuspend by setting the
.supports_autosuspend flagin its usb_driver structure. It is then responsible for informing theUSB core whenever one of its interfaces becomes busy or idle. Thedriver does so by calling these six functions:
The functions work by maintaining a usage counter in theusb_interface’s embedded device structure. When the counter is > 0then the interface is deemed to be busy, and the kernel will notautosuspend the interface’s device. When the usage counter is = 0then the interface is considered to be idle, and the kernel mayautosuspend the device.
Drivers need not be concerned about balancing changes to the usagecounter; the USB core will undo any remaining “get”s when a driveris unbound from its interface. As a corollary, drivers must not callany of the
usb_autopm_* functions after their
disconnectroutine has returned.
Drivers using the async routines are responsible for their ownsynchronization and mutual exclusion.
usb_autopm_get_interface() increments the usage counter anddoes an autoresume if the device is suspended. If theautoresume fails, the counter is decremented back.
usb_autopm_put_interface() decrements the usage counter andattempts an autosuspend if the new value is = 0.
usb_autopm_put_interface_async() do almost the same things astheir non-async counterparts. The big difference is that theyuse a workqueue to do the resume or suspend part of theirjobs. As a result they can be called in an atomic context,such as an URB’s completion handler, but when they return thedevice will generally not yet be in the desired state.
usb_autopm_put_interface_no_suspend() merely increment ordecrement the usage counter; they do not attempt to carry outan autoresume or an autosuspend. Hence they can be called inan atomic context.
The simplest usage pattern is that a driver calls
usb_autopm_get_interface() in its open routine and
usb_autopm_put_interface() in its close or release routine. But otherpatterns are possible.
The autosuspend attempts mentioned above will often fail for onereason or another. For example, the
power/control attribute might beset to
on, or another interface in the same device might not beidle. This is perfectly normal. If the reason for failure was thatthe device hasn’t been idle for long enough, a timer is scheduled tocarry out the operation automatically when the autosuspend idle-delayhas expired.
Autoresume attempts also can fail, although failure would mean thatthe device is no longer present or operating properly. Unlikeautosuspend, there’s no idle-delay for an autoresume.
Other parts of the driver interface¶
Drivers can enable autosuspend for their devices by calling:
probe() routine, if they know that the device is capable ofsuspending and resuming correctly. This is exactly equivalent towriting
auto to the device’s
power/control attribute. Likewise,drivers can disable autosuspend by calling:
This is exactly the same as writing
on to the
Sometimes a driver needs to make sure that remote wakeup is enabledduring autosuspend. For example, there’s not much pointautosuspending a keyboard if the user can’t cause the keyboard to do aremote wakeup by typing on it. If the driver sets
intf->needs_remote_wakeup to 1, the kernel won’t autosuspend thedevice if remote wakeup isn’t available. (If the device is alreadyautosuspended, though, setting this flag won’t cause the kernel toautoresume it. Normally a driver would set this flag in its
probemethod, at which time the device is guaranteed not to beautosuspended.)
If a driver does its I/O asynchronously in interrupt context, itshould call
usb_autopm_get_interface_async() before starting output and
usb_autopm_put_interface_async() when the output queue drains. Whenit receives an input event, it should call:
in the event handler. This tells the PM core that the device was justbusy and therefore the next autosuspend idle-delay expiration shouldbe pushed back. Many of the usb_autopm_* routines also make this call,so drivers need to worry only when interrupt-driven input arrives.
Asynchronous operation is always subject to races. For example, adriver may call the
usb_autopm_get_interface_async() routine at a timewhen the core has just finished deciding the device has been idle forlong enough but not yet gotten around to calling the driver’s
suspend method must be responsible for synchronizing withthe I/O request routine and the URB completion handler; it shouldcause autosuspends to fail with -EBUSY if the driver needs to use thedevice.
External suspend calls should never be allowed to fail in this way,only autosuspend calls. The driver can tell them apart by applyingthe
PMSG_IS_AUTO() macro to the message argument to the
suspendmethod; it will return True for internal PM events (autosuspend) andFalse for external PM events.
For external events – but not necessarily for autosuspend orautoresume – the device semaphore (udev->dev.sem) will be held when a
resume method is called. This implies that externalsuspend/resume events are mutually exclusive with calls to
post_reset; the USB core guarantees thatthis is true of autosuspend/autoresume events as well.
If a driver wants to block all suspend/resume calls during somecritical section, the best way is to lock the device and call
usb_autopm_get_interface() (and do the reverse at the end of thecritical section). Holding the device semaphore will block allexternal PM calls, and the
usb_autopm_get_interface() will prevent anyinternal PM calls, even if it fails. (Exercise: Why?)
Interaction between dynamic PM and system PM¶
Dynamic power management and system power management can interact ina couple of ways.
Firstly, a device may already be autosuspended when a system suspendoccurs. Since system suspends are supposed to be as transparent aspossible, the device should remain suspended following the systemresume. But this theory may not work out well in practice; over timethe kernel’s behavior in this regard has changed. As of 2.6.37 thepolicy is to resume all devices during a system resume and let themhandle their own runtime suspends afterward.
Secondly, a dynamic power-management event may occur as a systemsuspend is underway. The window for this is short, since systemsuspends don’t take long (a few seconds usually), but it can happen.For example, a suspended device may send a remote-wakeup signal whilethe system is suspending. The remote wakeup may succeed, which wouldcause the system suspend to abort. If the remote wakeup doesn’tsucceed, it may still remain active and thus cause the system toresume as soon as the system suspend is complete. Or the remotewakeup may fail and get lost. Which outcome occurs depends on timingand on the hardware and firmware design.
xHCI hardware link PM¶
xHCI host controller provides hardware link power management to usb2.0(xHCI 1.0 feature) and usb3.0 devices which support link PM. Byenabling hardware LPM, the host can automatically put the device intolower power state(L1 for usb2.0 devices, or U1/U2 for usb3.0 devices),which state device can enter and resume very quickly.
The user interface for controlling hardware LPM is located in the
power/ subdirectory of each USB device’s sysfs directory, that is, in
/sys/bus/usb/devices/../power/ where ”..” is the device’s ID. Therelevant attribute files are
USB Port Power Control¶
In addition to suspending endpoint devices and enabling hardwarecontrolled link power management, the USB subsystem also has thecapability to disable power to ports under some conditions. Power iscontrolled through
Set/ClearPortFeature(PORT_POWER) requests to a hub.In the case of a root or platform-internal hub the host controllerdriver translates
PORT_POWER requests into platform firmware (ACPI)method calls to set the port power state. For more background see theLinux Plumbers Conference 2012 slides  and video :
Upon receiving a
ClearPortFeature(PORT_POWER) request a USB port islogically off, and may trigger the actual loss of VBUS to the port .VBUS may be maintained in the case where a hub gangs multiple ports intoa shared power well causing power to remain until all ports in the gangare turned off. VBUS may also be maintained by hub ports configured fora charging application. In any event a logically off port will loseconnection with its device, not respond to hotplug events, and notrespond to remote wakeup events.
turning off a port may result in the inability to hot add a device.Please see “User Interface for Port Power Control” for details.
As far as the effect on the device itself it is similar to what a devicegoes through during system suspend, i.e. the power session is lost. AnyUSB device or driver that misbehaves with system suspend will besimilarly affected by a port power cycle event. For this reason theimplementation shares the same device recovery path (and honors the samequirks) as the system resume path for the hub.
USB 3.1 Section 10.12
wakeup note: if a device is configured to send wakeup events the portpower control implementation will block poweroff attempts on thatport.
User Interface for Port Power Control¶
The port power control mechanism uses the PM runtime system. Poweroff isrequested by clearing the
power/pm_qos_no_power_off flag of the port device(defaults to 1). If the port is disconnected it will immediately receive a
ClearPortFeature(PORT_POWER) request. Otherwise, it will honor the pmruntime rules and require the attached child device and all descendants to besuspended. This mechanism is dependent on the hub advertising port powerswitching in its hub descriptor (wHubCharacteristics logical power switchingmode field).
Note, some interface devices/drivers do not support autosuspend. Userspace mayneed to unbind the interface drivers before the
usb_device willsuspend. An unbound interface device is suspended by default. When unbinding,be careful to unbind interface drivers, not the driver of the parent usbdevice. Also, leave hub interface drivers bound. If the driver for the usbdevice (not interface) is unbound the kernel is no longer able to resume thedevice. If a hub interface driver is unbound, control of its child ports islost and all attached child-devices will disconnect. A good rule of thumb isthat if the ‘driver/module’ link for a device points to
/sys/module/usbcore then unbinding it will interfere with port powercontrol.
Example of the relevant files for port power control. Note, in this examplethese files are relative to a usb hub device (prefix):
In addition to these files some ports may have a ‘peer’ link to a port onanother hub. The expectation is that all superspeed ports have ahi-speed peer:
Distinct from ‘companion ports’, or ‘ehci/xhci shared switchover ports’peer ports are simply the hi-speed and superspeed interface pins thatare combined into a single usb3 connector. Peer ports share the sameancestor XHCI device.
While a superspeed port is powered off a device may downgrade itsconnection and attempt to connect to the hi-speed pins. Theimplementation takes steps to prevent this:
- Port suspend is sequenced to guarantee that hi-speed ports are powered-offbefore their superspeed peer is permitted to power-off. The implication isthat the setting
pm_qos_no_power_offto zero on a superspeed port maynot cause the port to power-off until its highspeed peer has gone to itsruntime suspend state. Userspace must take care to order the suspensionsif it wants to guarantee that a superspeed port will power-off.
- Port resume is sequenced to force a superspeed port to power-on prior to itshighspeed peer.
- Port resume always triggers an attached child device to resume. After apower session is lost the device may have been removed, or need reset.Resuming the child device when the parent port regains power resolves thosestates and clamps the maximum port power cycle frequency at the rate thechild device can suspend (autosuspend-delay) and resume (reset-resumelatency).
Link Electro Systems Port Devices Driver Download
Sysfs files relevant for port power control:
An advisory read-only flag to userspace indicating thelocation and connection type of the port. It returnsone of four values ‘hotplug’, ‘hardwired’, ‘not used’,and ‘unknown’. All values, besides unknown, are set byplatform firmware.
hotplug indicates an externally connectable/visibleport on the platform. Typically userspace would chooseto keep such a port powered to handle new deviceconnection events.
hardwired refers to a port that is not visible butconnectable. Examples are internal ports for USBbluetooth that can be disconnected via an externalswitch or a port with a hardwired USB camera. It isexpected to be safe to allow these ports to suspendprovided pm_qos_no_power_off is coordinated with anyswitch that gates connections. Userspace must arrangefor the device to be connected prior to the portpowering off, or to activate the port prior to enablingconnection via a switch.
notused refers to an internal port that is expectedto never have a device connected to it. These may beempty internal ports, or ports that are not physicallyexposed on a platform. Considered safe to bepowered-off at all times.
unknown means platform firmware does not provideinformation for this port. Most commonly refers toexternal hub ports which should be considered ‘hotplug’for policy decisions.
- since we are relying on the BIOS to get this ACPIinformation correct, the USB port descriptions maybe missing or wrong.
- Take care in clearing
pm_qos_no_power_off. Oncepower is off this port willnot respond to new connect events.
Once a child device is attached additional constraints areapplied before the port is allowed to poweroff.
- Must be
auto, and the port will notpower down until
<child>/power/runtime_statusreflects the ‘suspended’ state. Defaultvalue is controlled by child device driver.
- This defaults to
1for most devices and indicates ifkernel can persist the device’s configuration across apower session loss (suspend / port-power event). Whenthis value is
0(quirky devices), port poweroff isdisabled.
- Wakeup capable devices will block port poweroff. Atthis time the only mechanism to clear the usb-internalwakeup-capability for an interface device is to unbindits driver.
Summary of poweroff pre-requisite settings relative to a port device:
Suggested Userspace Port Power Policy¶
As noted above userspace needs to be careful and deliberate about whatports are enabled for poweroff.
Link Electro Systems Port Devices Driver Login
The default configuration is that all ports start with
power/pm_qos_no_power_off set to
1 causing ports to always remainactive.
Given confidence in the platform firmware’s description of the ports(ACPI _PLD record for a port populates ‘connect_type’) userspace canclear pm_qos_no_power_off for all ‘not used’ ports. The same can bedone for ‘hardwired’ ports provided poweroff is coordinated with anyconnection switch for the port.
Link Electrosystems Port Devices Driver
A more aggressive userspace policy is to enable USB port power off forall ports (set
0) whensome external factor indicates the user has stopped interacting with thesystem. For example, a distro may want to enable power off all USBports when the screen blanks, and re-power them when the screen becomesactive. Smart phones and tablets may want to power off USB ports whenthe user pushes the power button.