From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bin Meng Date: Thu, 7 Jan 2016 20:58:48 +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 Hi Fabio, On Thu, Jan 7, 2016 at 8:15 PM, Fabio Estevam wrote: > Hi Bin, > > On Thu, Jan 7, 2016 at 12:11 AM, Bin Meng 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