On Thu, 5 May 2011, Jan Andersson wrote: > >>> I assumed that the pci_write_config_word()s in uhci_*reset_hc would be > >>> needed in the case where GRUSBHC was used and there also was another > >>> UCHI controller connected via PCI in the system. After looking at the > >>> spec I suppose that it will work, as you say, without the writes to the > >>> legacy support register. > >> > >> Unless somebody decides to run a non-PCI-UHCI-enabled kernel in an x86 > >> PC. Maybe to be safe it would be best to rule out that combination in > >> the Kconfig: make USB_UHCI_SUPPORT_NON_PCI_HC depend on (USB_UHCI_HCD > >> && !X86). Would this be acceptable? > >> > > > > I am fine with that. Too bad that I managed to send V2 before seeing > > this message :-). I will wait for other comments on V2 before adding > > this in V3. > > > > Hmmm, after a bit more thought: I someone wants to run a > non-PCI-UHCI-enabled kernel in an x86 PC we would need one more config > option. I was assuming that no one would ever want to do this; in fact, that no one would ever want to build a kernel with support for both non-PCI-UHCI and x86. But maybe that's not a good assumption. > USB_UHCI_SUPPORT_NON_PCI_HC is currently needed to include the necessary > stuff for the non-PCI HC so that one must be set. One additional option > could be introduced to still include the accesses to the legacy support > register. Another way to solve this would be to add defined(CONFIG_X86) > in uhci-pci.c (change to patch 6 in V2): A better approach is for uhci-pci always to call the reset functions in pci-quirks. That's what you were planning to do originally, right? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
