On Mon, 31 Oct 2005, Linus Torvalds wrote:
> Well, this can't be right, because depending on which controller type it
> is, the handoff code uses PIO, not MMIO. In fact, a uhci controller
> wouldn't necessarily ever have PCI_COMMAND_MEMORY set afaik, since it
> doesn't even _have_ MMIO.
>
> Would something like the appended work instead?
>
> Linus
>
> ---
> diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
> index b7fd3f6..b1aa350 100644
> --- a/drivers/usb/host/pci-quirks.c
> +++ b/drivers/usb/host/pci-quirks.c
> @@ -138,11 +138,23 @@ reset_needed:
> }
> EXPORT_SYMBOL_GPL(uhci_check_and_reset_hc);
>
> +static inline int io_type_enabled(struct pci_dev *pdev, unsigned int mask)
> +{
> + u16 cmd;
> + return !pci_read_config_word(pdev, PCI_COMMAND, &cmd) && (cmd & mask);
> +}
> +
> +#define pio_enabled(dev) io_type_enabled(dev, PCI_COMMAND_IO)
> +#define mmio_enabled(dev) io_type_enabled(dev, PCI_COMMAND_MEMORY)
> +
> static void __devinit quirk_usb_handoff_uhci(struct pci_dev *pdev)
> {
> unsigned long base = 0;
> int i;
>
> + if (!pio_enabled(pdev))
> + return;
> +
In theory, is it possible for a UHCI controller still to be running, doing
DMA and/or generating interrupts, even if PCI_COMMAND_IO isn't set? If it
is, is there anything wrong with enabling the device fully in order to
shut it off?
Or is this scenario not worth worrying about?
Alan Stern
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
