[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180314085601.GD28796@lst.de>
Date: Wed, 14 Mar 2018 09:56:01 +0100
From: Christoph Hellwig <hch@....de>
To: Alexander Duyck <alexander.duyck@...il.com>
Cc: bhelgaas@...gle.com, alexander.h.duyck@...el.com,
linux-pci@...r.kernel.org, virtio-dev@...ts.oasis-open.org,
kvm@...r.kernel.org, netdev@...r.kernel.org, dan.daly@...el.com,
linux-kernel@...r.kernel.org, linux-nvme@...ts.infradead.org,
keith.busch@...el.com, netanel@...zon.com, ddutile@...hat.com,
mheyne@...zon.de, liang-min.wang@...el.com,
mark.d.rustad@...el.com, dwmw2@...radead.org, hch@....de,
dwmw@...zon.co.uk
Subject: Re: [pci PATCH v6 5/5] pci-pf-stub: Add PF driver stub for PFs
that function only to enable VFs
> +
> +/**
> + * pci_pf_stub_white_list - White list of devices to bind pci-pf-stub onto
> + *
> + * This table provides the list of IDs this driver is supposed to bind
> + * onto. You could think of this as a list of "quirked" devices where we
> + * are adding support for SR-IOV here since there are no other drivers
> + * that they would be running under.
> + *
> + * Layout of the table below is as follows:
> + * { Vendor ID, Device ID,
> + * SubVendor ID, SubDevice ID,
> + * Class, Class Mask,
> + * private data (not used) }
> + */
No need to document the PCI device table format in a random driver.
Otherwise looks fine:
Reviewed-by: Christoph Hellwig <hch@....de>
Powered by blists - more mailing lists