Re: [PATCH V2] PCI: rcar: Add L1 link state fix into data abort hook

[Marek Vasut <marek.vasut@gmail.com>]

On 10/5/20 9:31 AM, Geert Uytterhoeven wrote:
> Hi Marek,

Hi,

> On Sun, Oct 4, 2020 at 4:16 PM Marek Vasut <marek.vasut@gmail.com> wrote:
>> On 9/28/20 11:35 AM, Geert Uytterhoeven wrote:
>> [...]
>>>> +static int __init rcar_pcie_init(void)
>>>> +{
>>>> +#ifdef CONFIG_ARM_LPAE
>>>> +       hook_fault_code(17, rcar_pcie_aarch32_abort_handler, SIGBUS, 0,
>>>> +                       "asynchronous external abort");
>>>> +#else
>>>> +       hook_fault_code(22, rcar_pcie_aarch32_abort_handler, SIGBUS, 0,
>>>> +                       "imprecise external abort");
>>>> +#endif
>>>
>>> As there can be only a single handler, this may interfere with a handler
>>> for another platform in a multi-platform kernel.
>>> Hence I think this should not be done unconditionally, but be moved to
>>> the driver's .probe() callback.
>>
>> Why is nobody doing this in the probe code then ? It seems all the other
> 
> drivers/pci/controller/dwc/pci-keystone.c is:
> 
>   ks_pcie_probe()
>     ks_pcie_add_pcie_port()
>       dw_pcie_host_init()
>         pp->ops->host_init(pp) = ks_pcie_host_init()
>           hook_fault_code()

Well that one is interesting. I wonder whether that driver has the same
LPAE bug (different fault code for LPAE and non-LPAE configuration) we
found here too, since it is used on CA15 TI SoCs.

>> drivers which hook fault code do it in init as well. I can imagine that
> 
> Probably nobody bothered exercising the external abort handler on
> multi-platform kernels?
> 
>> something might trip the fault handler even before probe is called, e.g.
>> some PM handling or simply user accessing that PCIe area using setpci.
> 
> If that is the case, it must indeed by done earlier, but still
> conditional on the presence of the actual PCIe controller.

I am open to suggestions how to do that part.