Re: USB PCI quirk issue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Cc-ing the public Linux PCI and USB mailing lists.

On Fri, Apr 12, 2013 at 02:59:29PM -0400, Bulkow, David wrote:
> Susan,

I'm Sarah. :)

> While testing Linux 3.9 we ran into an issue which I believe is a
> conflict between a couple of PCI changes.  Stratus has hardware that
> can hot add/remove chunks of its PCI hierarchy which has tickled some
> of the newer code.  I am mailing you because I believe the second
> change I list below holds the key.
> 
> I believe we are experiencing a collision between two changes.  The
> first:
> 
> PCI: Put pci_dev in device tree as early as possible
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4f535093cf8f6da8cfda7c36c2c1ecd2e9586ee4
> 
> is causing device_add to be called during pci_scan_slot.  The second:
> 
> USB: Fix handoff when BIOS disables host PCI device
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=cab928ee1f221c9cc48d6615070fefe2e444384a
> 
> is getting activated by device_add.

So this system includes a Panther Point or Lynx Point xHCI host?

I'm running 3.9-rc6 with a Panther Point xHCI host, and it works fine,
so this is probably related to hot-plug, or perhaps a hardware-specific
issue.

> We are seeing complaints during pci_scan_slot like "BIOS handoff
> failed", "device not available... can't reserve IO" or mem for all USB
> devices.  Furthermore we are seeing the enable_cnt <= 0 warning,
> "disabling already-disabled device" in pci_disable_device during
> subsequent bringdown (or hot remove) operations.  We are using the
> protocol pci_scan_slot -> <assign IO/mem resources> ->
> pci_add_bus_resources to hot-add devices after they have been
> initialized.  I believe the first set of messages are because we have
> not yet assigned resources, but to do so the pci devices must be
> established - in pci_scan_slot.  The disable message is happening
> because the first failures during pci_scan_slot are over-decrementing
> enable_cnt in pci_enable_device_flags when do_pci_enable_device fails.

What are your BIOS settings for xHCI?  Some BIOSes have an option to
disable the xHCI host.  In that case, the BIOS won't respond to the xHCI
BIOS/OS handoff, and the xHCI PCI register that tells Linux which ports
are available to switch over from EHCI to xHCI will be all zeroes
(meaning we can't switch any ports over).

Originally, there was some talk of having the BIOS hide the PCI device
from the OS if the xHCI host was disabled in the BIOS.  I wonder if some
non-Intel BIOS vendor did that.

> What caught my eye in the second change, in usb quirk code, is that it
> does not differentiate between boot mode or hot-add operation. It is
> certainly possible we are doing PCI add incorrectly - things are
> moving quickly right now.

I don't understand why it should matter whether that code is run
directly after boot or on hot-add.  All that code does is read and write
the PCI MMIO registers, which should be available when the quirk is
called.

> Would you mind taking a look and correcting my understanding?

As for the other warnings, I think the PCI maintainer (Bjorn) is going
to have to address those, as I'm not a PCI expert.

Sarah Sharp
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux