| Message ID | 20181213175428.87520-2-sebott@linux.ibm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Delegated to: | Bjorn Helgaas |
| Headers | show |
| Series | [1/2] PCI: provide pcibios_sriov_add_vfs | expand |
On Thu, Dec 13, 2018 at 06:54:28PM +0100, Sebastian Ott wrote: > Implement pcibios_sriov_{add|del}_vfs as empty functions. VF > creation will be triggered by the hotplug code. And instead of having the arch suplply a no-op arch override I think it would be better to have the config option just stub it out in common code.
On Fri, Dec 14, 2018 at 05:12:45AM -0800, Christoph Hellwig wrote: > On Thu, Dec 13, 2018 at 06:54:28PM +0100, Sebastian Ott wrote: > > Implement pcibios_sriov_{add|del}_vfs as empty functions. VF > > creation will be triggered by the hotplug code. > > And instead of having the arch suplply a no-op arch override I > think it would be better to have the config option just stub it > out in common code. Or in fact maybe even a runtime flag in struct pci_dev. Who knows if all future s390 PCIe busses will have exactly the same behavior or if we eventually get the standards compliant behvior back?
On Fri, 14 Dec 2018, Christoph Hellwig wrote: > On Fri, Dec 14, 2018 at 05:12:45AM -0800, Christoph Hellwig wrote: > > On Thu, Dec 13, 2018 at 06:54:28PM +0100, Sebastian Ott wrote: > > > Implement pcibios_sriov_{add|del}_vfs as empty functions. VF > > > creation will be triggered by the hotplug code. > > > > And instead of having the arch suplply a no-op arch override I > > think it would be better to have the config option just stub it > > out in common code. > > Or in fact maybe even a runtime flag in struct pci_dev. Who knows > if all future s390 PCIe busses will have exactly the same behavior > or if we eventually get the standards compliant behvior back? Something like this: https://lore.kernel.org/linux-pci/20181212215453.GJ99796@google.com/T/#m649d86ea3c65f669c74d048f89afbaf473876ac3 Not a runtime flag, but a function pointer in struct pci_host_bridge. This would provide the requested flexibility. The problem with this approach is that it requires other patches that are not yet upstream (https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git/log/?h=pci-probe-rework). Since this discussion is going on since a few months and I want to have this code upstream and in distributions for HW enablement I've asked Bjorn to go with the initial approach (weak functions) and promised to move that to struct pci_host_bridge once Arnd's patches are upstream. Would that be OK for you too? Regards, Sebastian
On Mon, Dec 17, 2018 at 06:30:18PM +0100, Sebastian Ott wrote: > Something like this: > https://lore.kernel.org/linux-pci/20181212215453.GJ99796@google.com/T/#m649d86ea3c65f669c74d048f89afbaf473876ac3 No, I literally meant a flag to skip the work. Think about it: there is a standard way to probe VFs, which comes from what is defined in the PCIe spec itself. It just turns out s390 for some weird reason decides to already let the VFs show up basically like PFs. There really should be no reason to branch out into per-arch code here as there really isn't much to do on a per-arch level. More just a quirk for the firmware is buggy and already reports the VFs to us, so skip the probing.
diff --git a/arch/s390/pci/pci.c b/arch/s390/pci/pci.c index 9f6f392a4461..b5f8db652bf5 100644 --- a/arch/s390/pci/pci.c +++ b/arch/s390/pci/pci.c @@ -731,6 +731,17 @@ struct dev_pm_ops pcibios_pm_ops = { }; #endif /* CONFIG_HIBERNATE_CALLBACKS */ +#ifdef CONFIG_PCI_IOV +int pcibios_sriov_add_vfs(struct pci_dev *pdev, u16 num_vfs) +{ + return 0; +} + +void pcibios_sriov_del_vfs(struct pci_dev *pdev) +{ +} +#endif + static int zpci_alloc_domain(struct zpci_dev *zdev) { if (zpci_unique_uid) {
Implement pcibios_sriov_{add|del}_vfs as empty functions. VF creation will be triggered by the hotplug code. Signed-off-by: Sebastian Ott <sebott@linux.ibm.com> --- arch/s390/pci/pci.c | 11 +++++++++++ 1 file changed, 11 insertions(+)