[U-Boot] [PATCH 1/3] pci: Add error values definitions from the kernel
Bin Meng
bmeng.cn at gmail.com
Fri Jan 8 01:48:07 CET 2016
On Fri, Jan 8, 2016 at 8:46 AM, Bin Meng <bmeng.cn at gmail.com> wrote:
> Hi Fabio,
>
> On Thu, Jan 7, 2016 at 9:31 PM, Fabio Estevam <festevam at gmail.com> wrote:
>> On Thu, Jan 7, 2016 at 10:58 AM, Bin Meng <bmeng.cn at gmail.com> wrote:
>>
>>> 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.
>>
>> The problem only happens if we return a negative value.
>
> OK, now I am pretty sure this fix is not correct, that "the problem
> only happens if we return a negative value".
>
> The imx and layerscape PCIe driver registers PCI config ops as following:
>
> pci_set_ops(hose,
> pci_hose_read_config_byte_via_dword,
> pci_hose_read_config_word_via_dword,
> ls_pcie_read_config,
> pci_hose_write_config_byte_via_dword,
> pci_hose_write_config_word_via_dword,
> ls_pcie_write_config);
>
> The pci_hose_read_config_byte_via_dword() and
> pci_hose_read_config_word_via_dword() only return -1 if the error
> number < 0. What if I call:
>
> u32 data;
> ret = pci_read_config_dword(dev, PCI_VENDOR_ID, &data);
>
> This will fail with error number 0x86, but if we do:
>
> u16 data;
> ret = pci_read_config_dword(dev, PCI_VENDOR_ID, &data);
oops, this should be: pci_read_config_word()
>
> This will _not_ fail. This is inconsistent. You are just trying to
> workaround the 'pciinfo' command to make it output no error message.
>
>>
>>> And why returning zero is bad? From a working PCIe controller (either
>>
>> It is not bad, but I still prefer to keep in sync with the kernel driver.
>
> Regards,
> Bin
More information about the U-Boot
mailing list