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

[Gregory Fong <gregory.0xf0@gmail.com>]

Hi Leon,

On Thu, Jan 26, 2017 at 4:26 AM, Leon Woestenberg <leon@sidebranch.com> wrote:
> On Thu, Jan 26, 2017 at 11:08 AM, Bin Meng <bmeng.cn@gmail.com> wrote:
>
>>>> On Wed, Jan 25, 2017 at 1:25 PM, Gregory Fong <Gregory.Fong@virgingalactic.com> 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