From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gregory Fong Date: Thu, 26 Jan 2017 05:19:53 -0800 Subject: [U-Boot] [PATCH] pci: don't skip vendor ID 0 In-Reply-To: References: <1485321910-12648-1-git-send-email-gregory.fong@virgingalactic.com> <20170125212258.GA17043@10.34.70.57> 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 Leon, On Thu, Jan 26, 2017 at 4:26 AM, Leon Woestenberg wrote: > On Thu, Jan 26, 2017 at 11:08 AM, Bin Meng wrote: > >>>> On Wed, Jan 25, 2017 at 1:25 PM, Gregory Fong wrote: >>>>> I've been looking through the book I have on PCI and through various online >>>>> resources, and haven't been able to find evidence that a vendor ID of 0 is >>>>> invalid, even if it's unusual. >> >> Is it possible that it's zero due to the hardware is buggy? For >> example, on some Intel cards, PCI vendor ID and device ID can be >> loaded from an EEPROM and if EEPROM content is wrong, it may expose >> wrong IDs. Anyway zero does not look like a valid one though. >> > > From the spec. point of view, 0x0000 seems as valid as any in the range > [0x0001-0xFFFE]. > From the registry point of view, only registered numbers are valid. > > I.e. if I create a programmable PCI(e) card, I can pick any number in the > range [0x0000-0xFFFE] during development and it should work. I will try not > to clash with already registered numbers (to prevent the wrong drivers > probing the endpoint), and preferably I would try to re-use the (FPGA) > silicon vendor's ID, although I am well aware that it should change going > into production. Indeed, it turns out 0 doesn't tend to clash. :-) > > If only 0xFFFF is reserved, then [0-0xFFFE] should be accepted in the code, > right? > If we disallow 0x0000, on what arguments do we do that? Thanks for weighing in, this is exactly what I'm trying to find out. FWIW, the linux kernel works just fine with a vendor ID of 0. > > Middle solution is to accept the ID with a warning. Would the reason for the warning be that this change doesn't entirely fix the problem? If so, it seems like the place to put such a warning would be on the code that doesn't properly handle a vendor ID of 0 yet. But not sure it's necessary. I did take a quick look at what it would require to better handle the vendor ID 0 case everywhere. It looks like the main problem is that struct pci_device_id with vendor and device both 0 is being used to indicate the end of an array. Not that complicated to change, but it isn't trivial either, so figure it's best to leave for a future changeset. Thanks, Gregory