[PATCH v4 12/30] PCI: Introduce pci_host_bridge_ops to support host specific operations

[Yijing Wang]

On 2015/3/3 11:03, Bjorn Helgaas wrote:
> On Thu, Feb 26, 2015 at 04:12:06PM +0800, Yijing Wang wrote:
>> Now we have weak functions like pcibios_root_bridge_prepare()
>> to setup pci host bridge, We could introduce pci_host_bridge_ops
>> which contain host bridge specific ops to setup pci_host_bridge.
>> Then host bridge driver could add pci_host_bridge_ops hooks
>> intead of weak function to setup pci_host_bridge.
>> This patch add following pci_host_bridge_ops hooks:
>>
>> pci_host_bridge_ops {
>> 	/* set root bus speed, some platform need this like powerpc */
>> 	void (*phb_set_root_bus_speed)(struct pci_host_bridge *host);
>> 	/* setup pci_host_bridge before pci_host_bridge be added to driver core */
>> 	int (*phb_prepare)(struct pci_host_bridge *host);
>> 	/* platform specific of scan hook to scan pci device */
>> 	void (*phb_of_scan_bus)(struct pci_host_bridge *);
>> }
>> We could easily extend it to support different host bridge
>> specific operations.
>>
>> Signed-off-by: Yijing Wang <wangyijing at huawei.com>
>> ...
> 
>> @@ -2050,10 +2052,13 @@ static struct pci_bus *__pci_scan_root_bus(
>>  		pci_bus_insert_busn_res(b, b->number, 255);
>>  	}
>>  
>> -	max = pci_scan_child_bus(b);
>> -
>> -	if (!found)
>> -		pci_bus_update_busn_res_end(b, max);
>> +	if (host->ops && host->ops->phb_of_scan_bus) {
>> +		host->ops->phb_of_scan_bus(host);
> 
> The important thing here is not the use of OF (Open Firmware/Device Tree),
> is it?  Why would we want "_of_" in the function name?  I assume the intent
> is that this host bridge op performs the same function as
> pci_scan_child_bus(), so I think the op should be called "scan_bus".

Yes, because now only OF code need the private scan_child_bus, so I named it
phb_of_scan_bus(). I agree that rename it to scan_bus.

> 
>> +	} else {
>> +		max = pci_scan_child_bus(b);
>> +		if (!found)
>> +			pci_bus_update_busn_res_end(b, max);
>> +	}
>>  
>>  	return b;
>>  }
> 
> .
> 


-- 
Thanks!
Yijing