From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gregory Fong Date: Wed, 25 Jan 2017 21:23:03 +0000 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> Message-ID: <20170125212258.GA17043@10.34.70.57> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Bin, On Wed, Jan 25, 2017 at 10:14:56PM +0800, Bin Meng wrote: > Hi Gregory, > > On Wed, Jan 25, 2017 at 1:25 PM, Gregory Fong > wrote: > > Unlike 0xffff, 0 is not an invalid vendor ID. > > > > Signed-off-by: Gregory Fong > > --- > > Based on question initially asked here: > > http://lists.denx.de/pipermail/u-boot/2016-December/276172.html > > > > 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. There are still issues in how this will be > > handled in e.g. drivers/pci/pci_common.c because pci_hose_find_devices() still > > assumes that a vendor and device ID of 0 mean that the last pci_device_id is > > reached, but this change at least allows the device's PCI BARs to get > > programmed if the vendor ID is 0. > > > > [snip] > > Do you have such a PCI device that has the vendor ID as zero? Or have > you ever seen such? If not, I would say let's leave this as it is. Yes, this hardware does exist; that's the reason I stumbled across this issue at all. Without this change, the device's PCI BARs don't get programmed, so it isn't usable after booting the OS. I would have greatly preferred to be able to say that a vendor ID of 0 is invalid, but can't find any documentation to back up that assertion. Hence the patch. Best regards, Gregory