[U-Boot] [PATCH 1/3] pci: Add error values definitions from the kernel

[Bin Meng]

Hi Fabio,

On Thu, Jan 7, 2016 at 8:15 PM, Fabio Estevam <festevam at gmail.com> wrote:
> Hi Bin,
>
> On Thu, Jan 7, 2016 at 12:11 AM, Bin Meng <bmeng.cn at gmail.com> wrote:
>
>> Why should we introduce another set of error values just to fix this
>
> We should better align this with the kernel code.
>
>> specific PCIe issue? Isn't -EINVAL enough?
>
> Returning -EINVAL is what we do today and it causes the issue when
> running 'pci 0' command on imx and layerscape.

Ah, yes! Sorry I wanted to say the original proposal to "return 0"
instead. But now I failed to understand why this fixed the issue
because those error numbers are not zero.

>
> With this series we get the following results:
>
> 1. Do not get the error when running 'pci 0' command
>
> 2. Align the PCI return error code with the kernel.
>

But if we introduce those error numbers, we should promote its usage
in the PCI codes. Otherwise I fail to see its value as it is just used
in one or two drivers.

> Both are good things IMHO.
>

And why returning zero is bad? From a working PCIe controller (either
the one in those Freescale's PowerPC processors, or Intel's), when
probing a non-existent PCI device, the controller just returns
0xFFFFFFFF automatically in its register (done by hardware), and
nothing fails there (IOW, PCI config read op returns zero for these
controllers). Based on my read of the imx and layerscape PCIe driver,
it looks we are trying to workaround the buggy hardware as it returns
0xFFFFFFFF in a pure software way.

Regards,
Bin