[PATCH v2 2/5] powerpc/pci: Create pci_dn on demand
Sergey Miroshnichenko
s.miroshnichenko at yadro.com
Tue Sep 11 01:51:46 AEST 2018
Hello Sam,
On 9/10/18 7:47 AM, Sam Bobroff wrote:
> Hi Sergey,
>
> On Thu, Sep 06, 2018 at 02:57:49PM +0300, Sergey Miroshnichenko wrote:
>> The pci_dn structures can be created not only from DT, but also
>> directly from newly discovered PCIe devices, so allocate them
>> dynamically.
>>
>> Signed-off-by: Sergey Miroshnichenko <s.miroshnichenko at yadro.com>
>> ---
>> arch/powerpc/kernel/pci_dn.c | 76 ++++++++++++++++++++++++++++--------
>> 1 file changed, 59 insertions(+), 17 deletions(-)
>>
>> diff --git a/arch/powerpc/kernel/pci_dn.c b/arch/powerpc/kernel/pci_dn.c
>> index ab147a1909c8..48ec16407835 100644
>> --- a/arch/powerpc/kernel/pci_dn.c
>> +++ b/arch/powerpc/kernel/pci_dn.c
>> @@ -33,6 +33,8 @@
>> #include <asm/firmware.h>
>> #include <asm/eeh.h>
>>
>> +static struct pci_dn *create_pdn(struct pci_dev *pdev, struct pci_dn *parent);
>> +
>> /*
>> * The function is used to find the firmware data of one
>> * specific PCI device, which is attached to the indicated
>> @@ -58,6 +60,9 @@ static struct pci_dn *pci_bus_to_pdn(struct pci_bus *bus)
>> pbus = pbus->parent;
>> }
>>
>> + if (!pbus->self && !pci_is_root_bus(pbus))
>> + return NULL;
>> +
>> /*
>> * Except virtual bus, all PCI buses should
>> * have device nodes.
>> @@ -65,13 +70,15 @@ static struct pci_dn *pci_bus_to_pdn(struct pci_bus *bus)
>> dn = pci_bus_to_OF_node(pbus);
>> pdn = dn ? PCI_DN(dn) : NULL;
>>
>> + if (!pdn && pbus->self)
>> + pdn = pbus->self->dev.archdata.pci_data;
>> +
>> return pdn;
>> }
>>
>> struct pci_dn *pci_get_pdn_by_devfn(struct pci_bus *bus,
>> int devfn)
>> {
>> - struct device_node *dn = NULL;
>> struct pci_dn *parent, *pdn;
>> struct pci_dev *pdev = NULL;
>>
>> @@ -80,17 +87,10 @@ struct pci_dn *pci_get_pdn_by_devfn(struct pci_bus *bus,
>> if (pdev->devfn == devfn) {
>> if (pdev->dev.archdata.pci_data)
>> return pdev->dev.archdata.pci_data;
>> -
>> - dn = pci_device_to_OF_node(pdev);
>> break;
>> }
>> }
>>
>> - /* Fast path: fetch from device node */
>> - pdn = dn ? PCI_DN(dn) : NULL;
>> - if (pdn)
>> - return pdn;
>> -
>
> Why is it necessary to remove the above fast-path?
>
It is not, actually - this had leaked from early stages of debugging,
when I've found that after hotplug+rescan or hotplug+kexec the kernel
took pdns from device nodes that do not represent the actual PCIe
topology anymore. But after patches 3 and 4 the PCI_DN() is NULL for
every PCIe device except root on PowerNV, so this block is safe.
It will remain in version 3 of this patchset.
>> /* Slow path: fetch from firmware data hierarchy */
>> parent = pci_bus_to_pdn(bus);
>> if (!parent)
>> @@ -128,16 +128,9 @@ struct pci_dn *pci_get_pdn(struct pci_dev *pdev)
>> if (!parent)
>> return NULL;
>>
>> - list_for_each_entry(pdn, &parent->child_list, list) {
>> - if (pdn->busno == pdev->bus->number &&
>> - pdn->devfn == pdev->devfn)
>> - return pdn;
>> - }
>
> Could you explain why the above block was removed? Is it now impossible
> for it to find a pdn?
>
I see now that this block was also removed too early: on PowerNV with
this patchset it is impossible to have pdn being present in
parent->child_list but not in pdev->dev.archdata.pci_data; but this may
be not the case for pSeries.
>> -
>> - return NULL;
>> + return create_pdn(pdev, parent);
>> }
>>
>> -#ifdef CONFIG_PCI_IOV
>> static struct pci_dn *add_one_dev_pci_data(struct pci_dn *parent,
>> int vf_index,
>> int busno, int devfn)
>> @@ -156,7 +149,9 @@ static struct pci_dn *add_one_dev_pci_data(struct pci_dn *parent,
>> pdn->parent = parent;
>> pdn->busno = busno;
>> pdn->devfn = devfn;
>> + #ifdef CONFIG_PCI_IOV
>> pdn->vf_index = vf_index;
>> + #endif /* CONFIG_PCI_IOV */
>> pdn->pe_number = IODA_INVALID_PE;
>> INIT_LIST_HEAD(&pdn->child_list);
>> INIT_LIST_HEAD(&pdn->list);
>
> I can see that this change allows you to re-use this to set up a pdn in
> create_pdn(). Perhaps you should refactor pci_add_device_node_info() to
> use it as well, now that it's possible?
>
Sure, will do.
>> @@ -164,7 +159,54 @@ static struct pci_dn *add_one_dev_pci_data(struct pci_dn *parent,
>>
>> return pdn;
>> }
>> -#endif
>> +
>> +static struct pci_dn *create_pdn(struct pci_dev *pdev, struct pci_dn *parent)
>> +{
>> + struct pci_dn *pdn = NULL;
>> +
>> + pdn = add_one_dev_pci_data(parent, 0, pdev->bus->number, pdev->devfn);
>> + dev_info(&pdev->dev, "Create a new pdn for devfn %2x\n", pdev->devfn / 8);
>> +
>> + if (pdn) {
>> + #ifdef CONFIG_EEH
>> + struct eeh_dev *edev;
>> + #endif /* CONFIG_EEH */
>> + u32 class_code;
>> + u16 device_id;
>> + u16 vendor_id;
>> +
>> + #ifdef CONFIG_EEH
>> + edev = eeh_dev_init(pdn);
>> + if (!edev) {
>> + kfree(pdn);
>> + dev_err(&pdev->dev, "%s: Failed to allocate edev\n", __func__);
>> + return NULL;
>> + }
>> + #endif /* CONFIG_EEH */
>> +
>> + pdn->busno = pdev->bus->busn_res.start;
>
> It seems strange that pdn->busno is set by the call to
> add_one_dev_pci_data() above (to pdev->bus->number) and then overwritten
> here with a different value. Should add_one_dev_pci_data() use
> pdev->bus->busn_res.start and this line be removed?
>
Thanks for capturing that! I'll prepare v3 with the fixes.
>> +
>> + pci_bus_read_config_word(pdev->bus, pdev->devfn,
>> + PCI_VENDOR_ID, &vendor_id);
>> + pdn->vendor_id = vendor_id;
>> +
>> + pci_bus_read_config_word(pdev->bus, pdev->devfn,
>> + PCI_DEVICE_ID, &device_id);
>> + pdn->device_id = device_id;
>> +
>> + pci_bus_read_config_dword(pdev->bus, pdev->devfn,
>> + PCI_CLASS_REVISION, &class_code);
>> + class_code >>= 8;
>> + pdn->class_code = class_code;
>> +
>> + pdn->pci_ext_config_space = 0;
>> + pdev->dev.archdata.pci_data = pdn;
>> + } else {
>> + dev_err(&pdev->dev, "%s: Failed to allocate pdn\n", __func__);
>> + }
>> +
>> + return pdn;
>> +}
>
>
>>
>> struct pci_dn *add_dev_pci_data(struct pci_dev *pdev)
>> {
>> --
>> 2.17.1
>>
Best regards,
Serge
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20180910/7ef0d4f7/attachment-0001.sig>
More information about the Linuxppc-dev
mailing list