Hello all,
took several hours to trace this, with the very generous help of Alan Stern.
My serial adapters (FTDI 8U232AM, FTDI 232RL, pl2303) kept locking up
USB in case they had been open()ed.
This also caused FHEM to fail communicating with my home automation
interface (_almost_ always, curiously).
If one does a
diff -uN linux-2.6.27.7/drivers/usb/host/ehci-orion.c
linux-2.6.31.9/drivers/usb/host/ehci-orion.c |less
, this results in the following:
--- linux-2.6.27.7/drivers/usb/host/ehci-orion.c 2008-11-21
00:02:37.000000000 +0100
+++ linux-2.6.31.9/drivers/usb/host/ehci-orion.c 2009-12-18
22:47:01.000000000 +0100
@@ -33,8 +33,9 @@
/*
* Implement Orion USB controller specification guidelines
*/
-static void orion_usb_setup(struct usb_hcd *hcd)
+static void orion_usb_phy_v1_setup(struct usb_hcd *hcd)
{
+ /* The below GLs are according to the Orion Errata document */
/*
* Clear interrupt cause and mask
*/
@@ -104,6 +105,7 @@
struct ehci_hcd *ehci = hcd_to_ehci(hcd);
int retval;
+ ehci_reset(ehci);
retval = ehci_halt(ehci);
if (retval)
return retval;
@@ -117,7 +119,6 @@
hcd->has_tt = 1;
- ehci_reset(ehci);
ehci_port_power(ehci, 0);
return retval;
@@ -148,6 +149,7 @@
.urb_enqueue = ehci_urb_enqueue,
.urb_dequeue = ehci_urb_dequeue,
.endpoint_disable = ehci_endpoint_disable,
+ .endpoint_reset = ehci_endpoint_reset,
/*
* scheduling support
@@ -163,6 +165,8 @@
.bus_resume = ehci_bus_resume,
.relinquish_port = ehci_relinquish_port,
.port_handed_over = ehci_port_handed_over,
+
+ .clear_tt_buffer_complete = ehci_clear_tt_buffer_complete,
};
static void __init
@@ -186,7 +190,7 @@
}
}
-static int __init ehci_orion_drv_probe(struct platform_device *pdev)
+static int __devinit ehci_orion_drv_probe(struct platform_device *pdev)
{
struct orion_ehci_data *pd = pdev->dev.platform_data;
struct resource *res;
@@ -258,9 +262,19 @@
ehci_orion_conf_mbus_windows(hcd, pd->dram);
/*
- * setup Orion USB controller
+ * setup Orion USB controller.
*/
- orion_usb_setup(hcd);
+ switch (pd->phy_version) {
+ case EHCI_PHY_NA: /* dont change USB phy settings */
+ break;
+ case EHCI_PHY_ORION:
+ orion_usb_phy_v1_setup(hcd);
+ break;
+ case EHCI_PHY_DD:
+ case EHCI_PHY_KW:
+ default:
+ printk(KERN_WARNING "Orion ehci -USB phy version isn't
supported.\n");
+ }
err = usb_add_hcd(hcd, irq, IRQF_SHARED | IRQF_DISABLED);
if (err)
Many of those changes should have found their way into a _modified_
target/linux/brcm47xx/patch-2.6.30/270-ehci-ssb.patch in the 2.6.30 time frame
(or even earlier?), but unfortunately they didn't.
In the case of .clear_tt_buffer_complete, this proved to be fatal (causing
clearing_tt to never
get reset, thus ehci_endpoint_disable() to keep looping after pulling a
previously open()ed device,
thus locking up the entire USB device management).
(and possibly the .port_handed_over stuff is also missing, needs checking which
kernel version
was the last one that we had been in sync with)
Note that the USB storage I booted from kept working all the time,
fortunately.
Now that this annoying issue is out of the way, how to go forward?
I've been mailing previously about a build fix in ehci-ssb.c, with no reply.
And a subsequent svn update then managed to lock up kernel boot completely
(likely due to kernel lzma updates, the kernel didn't seem to load at all
despite unaltered .config).
I could now do another svn update but am tempted to avoid that given that things
started working with my pre-December svn state.
I could offer a diff to get ehci-ssb.c to a working state (also including the
unexported
static function fix that I mailed previously), and somebody could then apply it
and quilt refresh it on a current svn tree.
And I would be very pleased if ehci-ssb.c could find its way into mainline
pretty soon,
since this entire matter simply was a trivial but sadly effectful out-of-sync
with mainline issue.
Any thoughts?
Thanks,
Andreas Mohr
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
