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 devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html