On Wed, Apr 10, 2013 at 7:50 PM, Yijing Wang <wangyijing@xxxxxxxxxx> wrote: >>> Hi Bjorn, >>> Thanks for review. >>> >>>> My goal is that a user should never have to specify a kernel boot >>>> parameter or edit a modules.conf file, but the user did previously >>>> have some way to influence whether we use pciehp or acpiphp. I know >>>> we still have some issues, particularly with acpiphp, so I'm a little >>>> concerned that by removing the CONFIG_HOTPLUG_PCI_ACPI=m, we might be >>>> removing a way to work around those issues. >>>> >>>> A distro that previously used CONFIG_HOTPLUG_PCI_ACPI=m will now have >>>> to use =y, so modules.conf is no longer applicable. Can you convince >>>> me that the user still has a way to work around issues? I spent quite >>>> a while trying to understand the pciehp/acpiphp dependencies, but it's >>>> pretty tangled web. >>> I will try my best to explain the relationships between pciehp and acpiphp >>> as of v3.9-rc6. >>> >>> The pciehp driver always have priority over the acpiphp driver. >>> That is, the acpiphp driver rejects binding to an ACPI PCI hotplug slot if >>> a) The slot's parent is a PCIe port with native hotplug capability >>> b) OSPM has taken over PCIe native hotplug control from BIOS. >>> !(root->osc_control_set & OSC_PCI_EXPRESS_NATIVE_HP_CONTROL) >>> The above check has no dependency on the loading order of pciehp and acpiphp >>> drivers. So converting acpiphp driver to builit-in should be ok. >>> >>> On the other hand, I remember Yinghai has mentioned that some PCIe ports >>> with native hotplug capability doesn't work as expected with the pciehp driver >>> and should be managed by the acpiphp driver. Currently we could achieve that >>> by using boot param "pcie_ports=compat", but this will disable PCIe port >>> drivers altogether. And I also remember that Rafael has mentioned that >>> some BIOSes exhibit strange dependency among PCIe OSC controls, so it's >>> not feasible to only disable PCIe native hotplug. >>> >>> For "pciehp_force", it does only affect the way pciehp to detect a hotplug >>> slot, it doesn't affect acpiphp at all. >>> >>> To sum up, converting acpiphp as built-in should not affect the relationship >>> between pciehp and acpiphp driver. >> >> My concern is that a user used to be able to remove acpiphp from >> modules.conf. Now removing acpiphp will require a kernel rebuild. >> But maybe that won't turn out to be a problem. > > Hi Bjorn, > If user don't want to occupy the slot by acpiphp. Conservative approach, what about add a kernel parameter > to control acpiphp to enumerate slot ? Yes, that's what I'm thinking. A "Please report a bug if you have to use this parameter" chicken switch. Hopefully nobody will need to use it, but if somebody *does* need it, it's a lot better than having to tell him to rebuild the kernel. 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
