From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bin Meng Date: Fri, 8 Jan 2016 08:48:07 +0800 Subject: [U-Boot] [PATCH 1/3] pci: Add error values definitions from the kernel In-Reply-To: References: <1452113598-32409-1-git-send-email-festevam@gmail.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Fri, Jan 8, 2016 at 8:46 AM, Bin Meng wrote: > Hi Fabio, > > On Thu, Jan 7, 2016 at 9:31 PM, Fabio Estevam wrote: >> On Thu, Jan 7, 2016 at 10:58 AM, Bin Meng 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