Re: OHCI_QUIRK_INITRESET (was: 2.6.9-rc2-mm2 ohci_hcd doesn't work)

[Ingo Molnar]

* Rui Nuno Capela <rncbc@xxxxxxxxx> wrote:

> Then, in a silent suggestion from David Brownell, I hacked ohci_hcd.c,
> forcing the OHCI_QUIRK_INITRESET flag behaviour, build a new kernel and
> modules and voila', all USB is back to functionality.

> diff -duPNr linux.0/drivers/usb/host/ohci-hcd.c linux.1/drivers/usb/host/ohci-hcd.c
> --- linux.0/drivers/usb/host/ohci-hcd.c	2004-09-24 11:07:00.982690336 +0100
> +++ linux.1/drivers/usb/host/ohci-hcd.c	2004-09-24 11:19:06.232435616 +0100
> @@ -564,11 +564,12 @@
>  	 * (SiS, OPTi ...), so reset again instead.  SiS doesn't need
>  	 * this if we write fmInterval after we're OPERATIONAL.
>  	 */
> -	if (ohci->flags & OHCI_QUIRK_INITRESET) {
> +	 ohci_dbg(ohci, "OHCI_QUIRK_INITRESET forced!\n");
> +/*	if (ohci->flags & OHCI_QUIRK_INITRESET) { */
>  		writel (ohci->hc_control, &ohci->regs->control);
>  		// flush those writes
>  		(void) ohci_readl (&ohci->regs->control);
> -	}
> +/*	} */
>  	writel (ohci->fminterval, &ohci->regs->fminterval);

it would be cleaner to make this dependent on your chipset/vendor-id -
look how OHCI_QUIRK_INITRESET gets activated for e.g. SiS
(PCI_VENDOR_ID_SI) and OPTi (PCI_VENDOR_ID_OPTI). What is your box's
pdev->vendor and pdev->device? (lspci -v) (If it's indeed a quirk that
is needed, not some other fix.)

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/