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

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

On 10/12/20 9:18 AM, Geert Uytterhoeven wrote:

[...]

>> --- a/drivers/pci/controller/pcie-rcar-host.c
>> +++ b/drivers/pci/controller/pcie-rcar-host.c
> 
>> @@ -1050,4 +1072,58 @@ static struct platform_driver rcar_pcie_driver = {
>>         },
>>         .probe = rcar_pcie_probe,
>>  };
>> +
>> +#ifdef CONFIG_ARM
>> +static int rcar_pcie_aarch32_abort_handler(unsigned long addr,
>> +               unsigned int fsr, struct pt_regs *regs)
>> +{
>> +       u32 pmsr;
>> +
>> +       if (!pcie_base || !__clk_is_enabled(pcie_bus_clk))
>> +               return 1;
>> +
>> +       pmsr = readl(pcie_base + PMSR);
>> +
>> +       /*
>> +        * Test if the PCIe controller received PM_ENTER_L1 DLLP and
>> +        * the PCIe controller is not in L1 link state. If true, apply
>> +        * fix, which will put the controller into L1 link state, from
>> +        * which it can return to L0s/L0 on its own.
>> +        */
>> +       if ((pmsr & PMEL1RX) && ((pmsr & PMSTATE) != PMSTATE_L1)) {
>> +               writel(L1IATN, pcie_base + PMCTLR);
>> +               while (!(readl(pcie_base + PMSR) & L1FAEG))
>> +                       ;
>> +               writel(L1FAEG | PMEL1RX, pcie_base + PMSR);
>> +               return 0;
>> +       }
>> +
>> +       return 1;
>> +}
>> +
>> +static const struct of_device_id rcar_pcie_abort_handler_of_match[] = {
> 
> __initconst (if you intend to keep this, see below).

I do, see below.

>> +       { .compatible = "renesas,pcie-r8a7779" },
>> +       { .compatible = "renesas,pcie-r8a7790" },
>> +       { .compatible = "renesas,pcie-r8a7791" },
>> +       { .compatible = "renesas,pcie-rcar-gen2" },
>> +       {},
>> +};
>> +
>> +static int __init rcar_pcie_init(void)
>> +{
>> +       if (of_find_matching_node(NULL, rcar_pcie_abort_handler_of_match)) {
> 
> I guess it doesn't really hurt to use the existing rcar_pcie_of_match[]
> instead? It just contains two additional entries, which will never match
> in the CONFIG_ARM=y case.

Unless you try to build 32bit kernel for the R-Car3, like they do e.g.
for RPi3. So I would prefer to keep this to handle that case too.

[...]