On Friday 26 December 2014 09:15 PM, Alan Stern wrote:
> On Thu, 25 Dec 2014, Peter Chen wrote:
>
>> Thanks for explaining it, but I am still not understand why we need unbind
>> the interface when we go to turn the port power off or reset the port if
>> the port is owned by kernel. I often need to do continual plug in/out
>> usb device test, in order to emulate it, I just toggle the power (vbus
>> on <--> vbus off), I did not find anything wrong.
> Power management in the kernel uses a simple rule: A device has to be
> at full power while it is in use.
>
> A hub port is considered to be in use almost always, because a device
> could be plugged into it at any time. There are a few exceptions to
> this. For example, if a USB-2 device is plugged in then we know that
> nothing can be connected to its peer USB-3 port (since they use the
> same physical connector) and so the USB-3 port can be powered down.
> Or if a device is in runtime suspend and it isn't enabled for wakeup
> then its port can be powered off. Or if the firmware tells us that the
> port is not accessible to the user and nothing is plugged into it, then
> we know that it will never be used.
>
> Nevertheless, in general ports are always considered to be in use and
> therefore are not powered down. If you want to change this, you have
> to add a mechanism (probably a sysfs file) to allow the user to tell
> the kernel that a particular port will not be used. Then the kernel
> will be free to power-off that port.
>
> On Thu, 25 Dec 2014, Deepak Das wrote:
>
>> Above patch does make sense but the original question was the reason
>> behind the turning port power back on. There was a commit ca9c9d0
>> which added the port power control sysfs entry, we ported that commit
>> back to our kernel for testing but power was turned back ON due to
>> above reason.
> Well, of course. That commit was not complete in itself; it was just
> part of a series. And there have been many more commits (more than 20)
> affecting that part of the hub driver since then. You can't expect to
> back-port just one commit and have it do exactly what you want.
>
>> I don't see any strong reason to keep this feature of hub reset.
> We keep it because the hub driver wants ports to remain powered on as
> long as they are in use.
>
>> In addition, Do you see any consequences if we allow userspace to control
>> port power if hub supports ?
> Yes. The kernel does not allow userspace to control power to _any_
> device. The kernel controls power, and it allows userspace to set the
> power policy (within limits).
>
> The current port-power policy options are very limited. There is no
> way for the user to tell the kernel that a port isn't going to be used.
> As I said to Peter above, you could add such a policy mechanism.
>
> Alan Stern
>
Kool, that was my argument with my client. We added a policy to
tell kernel that user wants to turn off the port . I already modified the port
power policy mechanism by adding following check :-
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -4456,7 +4456,8 @@ static void hub_port_connect_change(struct usb_hub *hub,
int port1,
test_bit(port1, hub->removed_bits)) {
/* maybe switch power back on (e.g. root hub was reset) */
- if ((wHubCharacteristics & HUB_CHAR_LPSM) < 2
+ if ((hub->ports[port1 - 1]->port_power_policy ==
USB_PORT_POWER_ON) &&
+ (wHubCharacteristics & HUB_CHAR_LPSM) < 2
&& !port_is_power_on(hub, portstatus))
set_port_feature(hdev, port1, USB_PORT_FEAT_POWER);
but the issue is that they don't want to use sysfs because they want their code
to be
platform independent so they are using libusb.
I understand and agree with your explaination regarding the power mechanism.
I think your previous patch where port should be claimed by userspace before
turning the
power off is the only way to achieve it. If you agree then I will go ahead and
make that
change.
with warm regards,
Deepak Das
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
