On Sat, Dec 27, 2014 at 05:29:47AM +0530, Deepak Das wrote:
> 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.
But it can't use kernel driver, it means both host and device need to
have special function driver, is it correct?
--
Best Regards,
Peter Chen
--
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
