David, Thanks for your assistance on this... On Mon, 02 May 2005 17:20:19 PDT, David Brownell wrote: >On Monday 02 May 2005 3:43 pm, Doug Maxey wrote: >> David, >> >> I am curious about which driver probes when a reconnect event is seen. > >I'm not sure I understand the question. If the USB device drops its >pullup (D+ for high/full speeds, D- for low speed) then it's sensed >by the host as a disconnect ... and it's then forced through a full >USB enumeration cycle. > >That starts first with EHCI (assuming it's on that port) ... then if >the line's not using high speed signaling after the reset completes, >it's handed off to the companion controller (which sounds like OHCI >in this case, but can also be UHCI). > > >> When using the Belkin F5U219 on either ppc or ppc64 systems, at some >> point, it appears the ehci driver gets involved. The problem is, there >> are only low speed devices (keyboards and mice) attached (and detached). >> The net result is that once this occurs, the attached device is never >> probed again, until the driver is reloaded. > >So this F5U219 thing is a low speed device? And for some reason it's >disconnecting itself, after which something doesn't work?
F5U219 is a 3 port PCI adapter card with NEC D720101GJ chipset. > > >> This is seen with both the 2.4 driver, and the latest 2.6. >> >> Maybe my underlying question is: How does the port steering get >> handled by linux? > >The handoff between EHCI to its companion controller is controlled >in the EHCI root hub code, by setting the OWNER bit. The hardware >handles the rest. So when the ehci driver is available (loaded), it always takes first shot at the ports, correct? > > >> What type of output would you like to see to show this? I don't have >> anything captured at the moment, but I should be able to get to a system >> to reproduce this on. > >I'm not clear what "this" is. The usual rule of thumb is to enable >CONFIG_USB_DEBUG and show the relevant enumeration events, from "dmesg". Ok. I should confess the folks that are seeing the problem at the nonce are doing some other "under the covers" things (bus_remove_device()) before reading the device registers, and seeing unexpected results. After a while, it appears ehci attempts to take over permanently, and resets the port registers to show the full complement of 15 ports, which are not really available. I will get some more detailed information. > >- Dave > > >> >> ++doug >> >> > ------------------------------------------------------- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
