From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gregory Fong Date: Thu, 26 Jan 2017 19:11:46 -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 On Thu, Jan 26, 2017 at 5:57 AM, Leon Woestenberg wrote: > > On Thu, Jan 26, 2017 at 2:19 PM, Gregory Fong > wrote: >> >> 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. >> > Hmm, then maybe 0xFFFF, 0xFFFF should be used to indicate the end of the > array. > > How does Linux handle the end of the array, while it also supports 0x0000, > 0x0000? Well, looking at http://lxr.free-electrons.com/source/drivers/pci/pci-driver.c , in pci_match_id(), it stops if !(vendor || subvendor || class_mask), so I'd hazard a guess that the device I have is working is because it has a nonzero class ID. Strictly speaking that is probably still invalid, but it's much less likely to happen. It also supports dynamic IDs for which it iterates over a linked list. Unfortunately there seems to be a fair bit of code relying on all 0s having a special meaning, and it looks like all PCI_ANY_ID has its own meaning as well based off of the fact that there's a static pci_device_id_any struct in there that's used if driver_override is set in the input struct pci_dev. I can't say more than that without digging into the log for that change or finding the users of the driver_override flag. Best regards, Gregory