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

Fabrice Gasnier fabrice.gasnier at st.com
Tue May 26 01:03:21 PDT 2015


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.
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.
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
>




More information about the linux-arm-kernel mailing list