LinuxKPI: pci: properly define PCI_ANY_ID

[bz]

Summary

PCI vendor/device/subvendor/subdevice IDs are all uint16_t.
If we pass PCI_ANY_ID to a properly typed function we get a warning
given -1U is an unsigned int and that is a different constant value
than uint16_t -1. Add the cast to avoid this problem.

Sponsored by: The FreeBSD Foundation
MFC after: 3 days

[emaste]

Hmm, Linux struct pci_device_id has a __u32 vendor, device
Do we use this in any context that would have a 32-bit var?

[bz]

In D50008#1140412, @emaste wrote:

Hmm, Linux struct pci_device_id has a __u32 vendor, device
Do we use this in any context that would have a 32-bit var?

Grml. I was passing it to [lkpi_]pci_get_device() but that's likely u_int on Linux too? So maybe I need to fix that instead.? But then struct pci_dev also has them as uint16_t in LinuxKPI? Did we go too BSD here and Linux was doing other things beyond the namespace? @jhb knows lots of PCI. Any reason some/all of Linux may have them as uint32_t rather than uint16_t?

[jhb]

The registers are 16-bit in the hardware. Linux might be using 32-bit ints just to be more efficient on architectures that don't handle shorts as well. What do the relevant APIs in Linux itself use for the types?

[bz]

In D50008#1141668, @jhb wrote:

The registers are 16-bit in the hardware. Linux might be using 32-bit ints just to be more efficient on architectures that don't handle shorts as well. What do the relevant APIs in Linux itself use for the types?

uint_t. I think I need to fix lkpi_]pci_get_device() which takes uint16_t but haven't had a chance to grep for it yet. Still fighting more changes to PCI to make the branch compile again. I'll update this here the next days.