On 04/12/2012 09:48 PM, Bjorn Helgaas wrote:
On Thu, Apr 12, 2012 at 9:19 AM, Don Dutile<ddutile@xxxxxxxxxx> wrote:
On 04/12/2012 12:06 AM, Matthew Wilcox wrote:
--> other arch compile problem source???
Well, this device is part of the x86 CPU. It's never going to be found
as part of any other architecture. Why force other architectures to
carry this quirk around?
Well, the trend to include more IO into chipsets tied to an arch
will probably increase over time, so such conditional quirks will
increase as well.
Sounds like the quirk tables need an arch-hook (linked list) to check
& traverse. Then such code can go into arch/<arch>/pci/quirks.c .
We do have arch/x86/pci/fixup.c already. I agree it'd be nice if it
had the same name as the generic quirks.c. Other than that, do you
think there's an advantage to adding some sort of explicit arch hook,
or is it sufficient that DECLARE_PCI_FIXUP...() uses the linker to
collect all the quirks (both generic and arch-specific)?
Bjorn
--
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
I didn't understand that DECLARE_PCI_FIXUP...() uses the linker to
collect all the quirks. if so, that WFM.
I do think the arch/<>/pci/fixup.c module should be renamed to quirks.c
so it's association with drivers/pci/quirks.c is (more) obvious.
fixup.c gives the impression it may be more like bios-related fixup,
and not quirk-related fixups.
--
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
