To answer Your questions:
*) the affected hub does report per port power switching correctly
*) whether it is an erratum or design I can tell You in case I get
a clear answer on that point.
The following patch works well for my problem and might be useful
(at least not harmful) in the common code path:
--- linux-2.6.21.3/drivers/usb/host/ehci-hub.c.orig Tue May 29 17:12:50
2007
+++ linux-2.6.21.3/drivers/usb/host/ehci-hub.c Tue May 29 12:19:47 2007
@@ -389,6 +389,18 @@ ehci_hub_status_data (struct usb_hcd *hc
buf [1] |= 1 << (i - 7);
status = STS_PCD;
}
+
+ /* The hub was supposed to disable port power autonomously on
over-current.
+ * However, not all hubs can be trusted to do this although
they need port
+ * power disabled in order to recover properly.
+ */
+ if (temp & PORT_OCC) {
+ if (HCS_PPC(ehci->hcs_params)){
+ temp &= ~(PORT_RWC_BITS | PORT_POWER);
+ writel (temp, &ehci->regs->port_status [i]);
+ }
+ }
+
}
/* FIXME autosuspend idle root hubs */
spin_unlock_irqrestore (&ehci->lock, flags);
- Christian
-----Original Message-----
From: David Brownell [mailto:[EMAIL PROTECTED]
Sent: Saturday, May 26, 2007 6:18 AM
To: linux-usb-devel@lists.sourceforge.net
Cc: Engelmayer Christian
Subject: Re: [linux-usb-devel] hub.c port power handling on over-current
On Friday 25 May 2007, Engelmayer Christian wrote:
> Hi all,
>
> If I am not mistaken the current policy is to leave port power
> enabled at all times during over-current situations and let
> the power provider handle current limitation.
More accurately: let the hub handle it. And ISTR that the
hub is supposed to automatically power off (or at least current
limit) ports observing overcurrent conditions.
Overcurrent has been a problem recently with EHCI; I'm not
entirely sure why. It'd be no surprise to find that there's
something the driver should do differently for some silicon.
In particular, we want root hubs to follow chapter 11 of the
USB spec ("hubs"). The hub driver in usbcore expects that.
But the details of that expectation have changed a lot over
the 2.6 cycle, and I suspect some root hubs have fallen a
bit behind ... not acting enough like a "real" hub.
> I experienced problems with the EHCI on an MPC8343E, which
> after some over-current situations no longer asserts the
> Connect Change Status Bit in the Port Status and Control Register,
> leading to the result that USB would be fully functional, but
> is no longer effectively serviced...
>
> The solution to this problem according to Freescale support
> would be to disable and re-enable port power after the over-current
> situation. Trying this with a hardware debugger gets us back in service.
Is this an erratum, or are they saying that's how they read
the EHCI spec? Does this EHCI report that it supports per-port
power switching? (Probe messages with USB_DEBUG enabled will
report that, as will current versions of "lsusb -v".)
I'd have to check, but I think that Linux won't currently turn
off per-port power unless the host controller reports that it
actually supports per-port power switching. And most EHCI
implementations don't report that in the hardware, so Linux
won't power it off ...
> As I am no big fan of work-arounds and rather new to the
> USB-subsystem, might I ask what would be an accaptable way
> to patch this behaviour?
One thing to try would be to make the root hub descriptor
report that it supports per-port power switching ... assuming
that the hardware says otherwise. ehci_hub_descriptor() is
the thing; or maybe HCS_PPC().
I'd have to look at usbcore's hub driver again to verify,
but I think that might be sufficient to change its behavior.
If not, you might also have to modify ehci_hub_status() to
power off ports when OCC is detected ... some silicon will
do that automatically, some won't, Linux could always do so.
In general what we'd like to have is one code path which
can work on all hardware. If you read the EHCI spec you'll
see it allows some implementation flexibility in this area;
if this isn't an erratum, I'd expect that what makes your
case work better would not hurt other EHCI implementations.
- Dave
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
