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

[Bin Meng]

Hi Gregory,

On Thu, Jan 26, 2017 at 5:23 AM, Gregory Fong
<Gregory.Fong at virgingalactic.com> wrote:
> 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 at virgingalactic.com> wrote:
>> > Unlike 0xffff, 0 is not an invalid vendor ID.
>> >
>> > Signed-off-by: Gregory Fong <gregory.fong at 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.
>

Which vendor is your PCI device manufactured by?

> 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.
>

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.

Regards,
Bin