On Tue, Nov 08, 2016 at 01:27:31PM +0100, Alexander Gordeev wrote:
> On Fri, Nov 04, 2016 at 05:41:01PM +0100, Andrew Jones wrote:
> > > /* Scan bus look for a specific device. Only bus 0 scanned for now. */
> > > -pcidevaddr_t pci_find_dev(uint16_t vendor_id, uint16_t device_id)
> > > +int pci_find_dev(struct pci_dev *pci_dev, uint16_t vendor_id, uint16_t device_id)
> > > {
> > > pcidevaddr_t dev;
> > >
> > > - for (dev = 0; dev < 256; ++dev) {
> > > + for (dev = 0; dev < PCI_DEVFN_MAX; ++dev) {
> >
> > Why introduce this PCI_DEVFN_MAX define?
> >
> > > if (pci_config_readw(dev, PCI_VENDOR_ID) == vendor_id &&
> > > - pci_config_readw(dev, PCI_DEVICE_ID) == device_id)
> > > - return dev;
> > > + pci_config_readw(dev, PCI_DEVICE_ID) == device_id) {
> > > + pci_dev_init(pci_dev, dev);
> > > + return 0;
> > > + }
> > > }
> > >
> > > - return PCIDEVADDR_INVALID;
> > > + return -1;
> >
> > Why not use bool for the ret type; true=good, false=bad?
>
> Both ways look strange to me. I would leave pci_find_dev() as is (low-
> level) and move pci_dev_init() outside - so a usage would be i.e.:
>
> dev = pci_find_dev(PCI_VENDOR_ID_REDHAT, PCI_DEVICE_ID_REDHAT_TEST);
> if (dev == PCIDEVADDR_INVALID)
> ...
> pci_dev_init(&pci_dev, dev);
IMHO actually it'll be nicer with:
struct pci_dev *pci_find_dev(uint16_t vendor_id, uint16_t device_id);
But this needs dynamic allocation of memory, which might be an
overkill for kvm-unit-test. So I chose to allocate the pci_dev on
caller stack.
Anyway, I take the interface issue as a matter of taste.
How about I take Drew's suggestion here with true/false? Then if we
have any better idea with solid reasons, we can post seperate patch
for it.
Thanks,
-- peterx
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
