Re: Query regarding root hub reset

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

 



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)

--
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