On Tuesday, July 27, 2010, Kenji Kaneshige wrote: > Hi, > > If I understand your patch correctly, the PCIe port services work > only when firmware grants all the controls for port services with > your patch. Correct? Yes, that's correct. > I think this will break PCIe services currently working. For example, > firmware doesn't grant PCIe AER control on my hardware. On the other > hand, firmware grants PCIe native hot-plug control on the same machine. > So I think PCIe hot-plug will not work with your patch. It won't, but the question is if it should. Namely, PCIe native hot-plug requires control of the PCIe capability structure, which is also used for AER, so the BIOS granting control of the PCIe capability structure and not granting control of AER is arguably broken. > Another example, what would happen on the platform that doesn't have any PCIe > hot-plug slot? I guess firmware doesn't grant PCIe native hot-plug control on > that environment. So I think all the other PCIe port services would > not work on such platform. You would be surprised. :-) > My suggestion is that > > (1) Query all controls for PCIe port services and see what controls > will be granted to OS by firmware. We do that already. > (2) Request all the controls acquired in step (1) at the same time. Yes, we can do that, although it would complicate things quite a bit and I'm not sure that's _really_ necessary, given that all of the native services require access to the PCIe capability structure and once _that_ is granted, the BIOS has no reason not to grant any other bits. > (3) Create PCIe port services for those controls. I don't really think (3) is necessary in that case. It should be OK not to load a service driver, in which case the service will simply be disabled. > What do you think about this? > > I think there is still a problem that needs to be addressed. The problem > is that if ACPIPHP (ACPI based hot-plug driver) is required for PCIe hot- > plug, all the PCIe port services needs to be disabled. I don't think it > is acceptable for ACPIPHP users. I'm not sure what you mean. The $subject patch (rather the last version of it at https://patchwork.kernel.org/patch/114127/) doesn't change the existing behavior in that respect other than PCIeHP will not be enabled without PME and possibly AER. Certainly, though, our current behavior is wrong, since all of the port service drivers request OSC_PCI_EXPRESS_CAP_STRUCTURE_CONTROL on their own, which leads to problems in real systems. Thanks, Rafael -- 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
