[RFC PATCH v1 1/3] PCI: designware: Add ARM64 support

[wangzhou1@hisilicon.com (Zhou Wang)]

On 2015/5/26 16:03, Fabrice Gasnier wrote:
> Hi zhou,
> 
> On 05/26/2015 04:49 AM, Zhou Wang wrote:
>>>   struct pcie_port {
>>> >+#ifdef CONFIG_ARM
>>> >+    /*
>>> >+     * this is a temporary hack to let the driver work on
>>> >+     * both arm32 and arm64. it can be removed after the
>>> >+     * arm32 cleanup is complete and bios32.c has stopped
>>> >+     * referencing host->pci_sys_data.
>>> >+     */
>>> >+    struct pci_sys_data    dummy;
>>> >+#endif
>>> >      struct device        *dev;
>>> >
>>> >
>>> >This looks like necessary as bios32 is dereferencing sysdata:
>>> >struct pci_sys_data *sysdata = dev->bus->sysdata;
>>> >
>>> >Best Regards,
>>> >Fabrice
>>> >
>> Hi Fabrice,
>>
>> Firstly, many thanks for your test:)
>>
>> I am a little confused that pci_sys_data is still needed as we don't use the code
>> in bios32. What was the problem you met? Could you share me more information? Then
>> let's see how to solve the problem.
> 
> This is not completely true: there is still code in bios32 that requires pci_sys_data.

Right.

> No matters pci_common_init_dev() is being called or not :
> 
> You can see pcibios_msi_controller() has a weak definition (in drivers/pci/msi.c).
> But bios32 defines it for arm. Then it's being used.

But here in dw_pcie_host_init, I directly set bus->msi = &dw_pcie_msi_chip. So in
drivers/pci/msi.c, we will get the msi controller by dev->bus->msi in pci_msi_controller.
It will not run into pcibios_msi_controller().

Maybe there is still something I miss understood, if so, please let me know.

Best Regards,
Zhou

> So, basically, pci_sys_data is still needed on arm. This is how above workaround proposed by Arnd takes care of it.
> Without this, dereferencing the pointer as done in bios32, makes it hazardous and lead to crashes...
> e.g. in pcibios_msi_controller(), pci_sys_data will point to "dev->bus->sysdata", aka "struct device *dev" above.
> 
> Best Regards,
> Fabrice
>>
>> Thanks again and Best Regards,
>> Zhou
>>
> 
> 
> .
>