On Tuesday, June 04, 2013 03:57:28 PM Yinghai Lu wrote: > On Tue, Jun 4, 2013 at 3:49 PM, Rafael J. Wysocki <rjw@xxxxxxxxxxxxx> wrote: > > On Wednesday, June 05, 2013 12:44:27 AM Rafael J. Wysocki wrote: > >> On Friday, May 31, 2013 12:21:30 PM Jiang Liu wrote: > >> > From: Yinghai Lu <yinghai@xxxxxxxxxx> > >> > > >> > When sriov is enabled, VF could just start after PF in pci tree. > >> > like c1:00.0 will be PF, and c1:00.1 and after will be VF. > >> > > >> > acpi do have dev with same ADR. that will make them get glued > >> > wrongly. > >> > >> How exactly are they glued in that case? > >> > >> > Skip that if it is virtfn. > >> > >> That should be a bit more specific as far as I can say. I don't see why a VF > >> would not have a valid ACPI device object corresponding to it. Is there any > >> particular reason? > > > > 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. May that be addressed in a more specific way? Also, I don't quite understand what the problem *exactly* is, because you haven't given any details so far. Can you possibly attach the specific piece of AML causing the problem to happen on your system? Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- 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
