Bug 9562

Created attachment 14040 [details]
patch to disable ehci support for the Philips ISP1561 usb hub

Can you send me this patch in email form, with the needed information as documented in Documentation/SubmittingPatches, and CC: the linux-usb mailing list so that I can apply it properly?

thanks.

Reply-To: akpm@linux-foundation.org


(added bugzilla to cc)

On Fri, 21 Dec 2007 22:02:28 -0800 David Brownell <david-b@pacbell.net> wrote:

> > > ---
> a/drivers/usb/host/ehci-pci.c~ehci-disable-the-philips-isp1561-usb-hub
> > > +++ a/drivers/usb/host/ehci-pci.c
> > > @@ -141,6 +141,14 @@ static int ehci_pci_setup(struct usb_hcd
> > >                   goto done;
> > >           }
> > >           break;
> > > + case PCI_VENDOR_ID_PHILIPS:
> > > +         /* ISP1561 EHCI USB 2.0 doesn't work. */
> > > +         if (pdev->device == 0x1562) {
> > > +                 ehci_info(ehci, "ignoring ISP1561\n");
> > > +                 retval = -EIO;
> > > +                 goto done;
> > > +         }
> > > +         break;
> > >   case PCI_VENDOR_ID_NVIDIA:
> > >           switch (pdev->device) {
> > >           /* Some NForce2 chips have problems with selective suspend;
> >
> > Is this really an appropriate approach?
> 
> Almost certainly not.  NAK on that patch.
> 
> 
> >     That is, is it definitely
> > known that there are no working devices of this type?  Or is it
> > possible that other people have ISP1561 EHCI controllers that they
> > actually do use?  If there are, blacklisting their devices like this 
> > would be a very bad idea.
> 
> I'll have to search through some boxes to be sure, but I'm all but
> certain it was an ISP1561, sent to me by Philips from Taiwan, that
> I used for a bunch of early EHCI work.  They have newer EHCI silicon,
> like the 1562, 1563, and 1564, and don't seem to have obsoleted any
> chip called the 1560, so it's hard to say what else it'd have been.
> 
> Whichever chip it was, it worked quite nicely ... it did help shake
> loose a couple low level races in the driver, since its timings
> were a bit different from the other chips I had, but after those
> got fixed it was rock solid.
> 
> Unfortunately I have a shortage of available PCI slots lately, so I
> can no longer to keep a dozen vendors' worth of EHCI controllers
> sitting in machines ready to test.  In fact I have no PCI slots
> available for such purposes at all.  :(
> 

so... what can we do about Bruno's bug?

Reply-To: david-b@pacbell.net

> > > > ---
> a/drivers/usb/host/ehci-pci.c~ehci-disable-the-philips-isp1561-usb-hub
> > > > +++ a/drivers/usb/host/ehci-pci.c
> > > > @@ -141,6 +141,14 @@ static int ehci_pci_setup(struct usb_hcd
> > > >                         goto done;
> > > >                 }
> > > >                 break;
> > > > +       case PCI_VENDOR_ID_PHILIPS:
> > > > +               /* ISP1561 EHCI USB 2.0 doesn't work. */
> > > > +               if (pdev->device == 0x1562) {
> > > > +                       ehci_info(ehci, "ignoring ISP1561\n");
> > > > +                       retval = -EIO;
> > > > +                       goto done;
> > > > +               }
> > > > +               break;
> > > >         case PCI_VENDOR_ID_NVIDIA:
> > > >                 switch (pdev->device) {
> > > >                 /* Some NForce2 chips have problems with selective
> suspend;
> > >
> > > Is this really an appropriate approach?
> > 
> > Almost certainly not.  NAK on that patch.
>
> so... what can we do about Bruno's bug?

Start by providing a usable bug description!  Bug 9562 is little more
than a description of the above hack ... it doesn't say anything about
just what went wrong.  There's a FAQ somewhere saying what we need in
bug reports...

That includes kernel logs of the startup when CONFIG_USB_DEBUG is enabled.
Start by loading both EHCI and OHCI driver modules loaded, then insert
that CardBus card.  Include all the output until the USB subsystem has
finished enumerating and hotplugging.

It should also include "lspci -vvx" output for that CardBus device.

Adding dmesg output with USB_DEBUG enabled both with the original driver and with the modified ehci-pci.c.
Also adding output from lspci -vv and lsusb -v

Created attachment 14417 [details]
dmesg output with original ehci-pci

Created attachment 14418 [details]
dmesg output with modified ehci-pci

Created attachment 14419 [details]
lspci -vv output

Created attachment 14420 [details]
lsusb -v output

Looks like the problem I noticed a while back where some patches broke OHCI.  I believe that's now fixed ... does 2.6.26-rc4 behave?

The handoff to the companion controller is not working here, and when I saw this with some other devices (with an almost-vanilla 2.6.25 kernel) the problem was that something was leaving the OHCI controller in the "reset" state ... you could see this by looking in the /sys/kernel/debug/ohci/.../registers file.

A 2.6.23 kernel is unfortunately not something I can try to debug.

The card is now working with 2.6.25-gentoo-r7 (based on 2.6.25.11)

Still need to know if the standard kernel.org tree behaves.  I have no idea what patches are applied to a Gentoo kernel.

It is working with kernel 2.6.25.12