[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