On Wed, Jun 5, 2013 at 9:55 AM, Yinghai Lu <yinghai@xxxxxxxxxx> wrote: > On Tue, Jun 4, 2013 at 4:51 PM, Rafael J. Wysocki <rjw@xxxxxxxxxxxxx> wrote: >> On Tuesday, June 04, 2013 03:57:28 PM Yinghai Lu wrote: >>> > >>> > To be precise, I don't quite see why it is impossible or invalid for a VF to >>> > have a corresponding ACPI device object. It may not be the case on this >>> > particular system, but why not in general? >>> >>> at least for ioapic routing GSI, we should not mix VF to use other PF's >>> setting. >> >> I can agree with that, but your patch is far more general than this. It won't >> allow any VF on any system to be "glued" to any ACPI device object and I'm >> thinking that that may just go too far. > > I think that we should look reversely: > Is there any reason or use case that we need to bind PCI VF to acpi device? > PCI vf is only showing up after PF driver call pci_enable_siov. I disagree with this sentiment. We should handle VFs the same as PFs except when that's impossible. You're proposing a special case of treating VFs differently, so I think the burden is on you to explain why we need to do that. It would be helpful if you answered the questions people ask you, for example, if you could supply the AML Rafael asked about. If it's secret, just say so instead of leaving us with the impression that you're ignoring the question. 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