[U-Boot] [PATCH] pci: don't skip vendor ID 0

From: Gregory Fong <Gregory.Fong@virgingalactic.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] pci: don't skip vendor ID 0
Date: Wed, 25 Jan 2017 21:23:03 +0000	[thread overview]
Message-ID: <20170125212258.GA17043@10.34.70.57> (raw)
In-Reply-To: <CAEUhbmV5U7xA_JCPFutr=vjDkpn-Lfw1not7-UFhdkG7yy3hrQ@mail.gmail.com>

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
> <Gregory.Fong@virgingalactic.com> wrote:
> > Unlike 0xffff, 0 is not an invalid vendor ID.
> >
> > Signed-off-by: Gregory Fong <gregory.fong@virgingalactic.com>
> > ---
> > 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