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
>>
>
>
> .
>
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
