On Wednesday 24 December 2014 09:55 PM, Alan Stern wrote:
> On Wed, 24 Dec 2014, Peter Chen wrote:
>
>> On Tue, Dec 23, 2014 at 03:15:45PM -0500, Alan Stern wrote:
>>> On Tue, 23 Dec 2014, Peter Chen wrote:
>>>
>>>>> The Linux USB stack supports turning off port power only under a very limited
>>>>> set of conditions. For example, if the port is hard-wired or not connected at all,
>>>>> and if remote wakeup is not required.
>>>>>
>>>> Alan, any reasons/limitations we do not support it (by libusb)?
>>> For the same reason we don't allow userspace to interfere with any
>>> device: When a kernel driver is in charge of a device, any changes the
>>> user wants to make must go through the driver. If users were allowed
>>> to make changes to a device without telling the driver, then the driver
>>> would not be able to do its job properly.
>> Why we can't turn port power off without unbinding driver?
>> I see we can reset device at devio, why we can reset a device, but
>> can't turn its port off?
> That's more or less a quirk of history. If we were doing it now, I
> might say that a user program should not be allowed to reset a device
> unless it has claimed at least one of the device's interfaces.
>
> However, that question does not have the right point of view. The
> problem with turning off port power isn't that it interferes with the
> driver of the device attached to that port; the problem is that it
> interferes with the hub driver.
>
> On the other hand, it would make sense to allow an exception for the
> case where userspace owns the port. The (untested) patch below would
> be acceptable, and it would allow Deepak to do what he wants.
>
>>> In fact, it's only a coincidence that Deepak's libusb call is able to
>>> succeed. Hub control messages use USB_RECIP_OTHER instead of
>>> USB_RECIP_INTERFACE, even though they are always meant to go to the hub
>>> interface. If the messages used USB_RECIP_INTERFACE then the kernel
>>> would prevent libusb from sending the message unless the user program
>>> first claimed the hub interface (which would mean unbinding the
>>> kernel's hub driver).
>>>
>> Some laptops turns off vbus during the system suspend, does the driver
>> is aware of it?
> Yes. If Vbus power is turned off during suspend then during resume the
> PORT_CSC bit will be set.
>
> Alan Stern
>
>
>
> Index: usb-3.18/drivers/usb/core/hub.c
> ===================================================================
> --- usb-3.18.orig/drivers/usb/core/hub.c
> +++ usb-3.18/drivers/usb/core/hub.c
> @@ -4661,9 +4661,13 @@ static void hub_port_connect(struct usb_
> if (!(portstatus & USB_PORT_STAT_CONNECTION) ||
> test_bit(port1, hub->removed_bits)) {
>
> - /* maybe switch power back on (e.g. root hub was reset) */
> - if (hub_is_port_power_switchable(hub)
> - && !port_is_power_on(hub, portstatus))
> + /*
> + * Maybe switch power back on (e.g. root hub was reset),
> + * but only if the port isn't owned by someone else.
> + */
> + if (hub_is_port_power_switchable(hub) &&
> + !port_is_power_on(hub, portstatus) &&
> + !port_dev->port_owner)
> set_port_feature(hdev, port1, USB_PORT_FEAT_POWER);
>
> if (portstatus & USB_PORT_STAT_ENABLE)
>
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. I don't see any strong reason to keep this feature of hub reset.
In addition, Do you see any consequences if we allow userspace to control
port power if hub supports ?
Thanks, Deepak Das
--
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
