[dpdk-dev] igb_uio: use existing PCI macros
Commit Message
To get pci_dev and vf number from dev, benefit from
existing macros in pci.h
Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
---
lib/librte_eal/linuxapp/igb_uio/igb_uio.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
Comments
Hello Ferruh,
On Thu, Sep 10, 2015 at 6:01 PM, Ferruh Yigit <ferruh.yigit@intel.com>
wrote:
> To get pci_dev and vf number from dev, benefit from
> existing macros in pci.h
>
> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
>
Correct me if I am wrong but you might need to provide wrappers for kernel
version <= 2.6.34 (or something that indicates availability of those).
Please, can you confirm this is just a cleanup and you are not fixing
anything ?
Thanks.
2015-09-10 20:33, Ferruh Yigit:
> > On Thu, Sep 10, 2015 at 6:01 PM, Ferruh Yigit <ferruh.yigit@intel.com>
> > wrote:
> >
> > > To get pci_dev and vf number from dev, benefit from
> > > existing macros in pci.h
> > >
> > > Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
> >
> > Correct me if I am wrong but you might need to provide wrappers for kernel
> > version <= 2.6.34 (or something that indicates availability of those).
>
> Correct, those macros available after kernel version >= 2.6.34.
> If these is any chance that one using older kernel than this version,
> instead of having wrappers I am for keeping existing implementation and
> drop this patch.
Why should we support kernel older than 2.6.34?
Do we need to update doc/guides/rel_notes/supported_os.rst?
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Friday, September 11, 2015 9:11 AM
> To: dev@dpdk.org; Yigit, Ferruh; David Marchand
> Subject: Re: [dpdk-dev] [PATCH] igb_uio: use existing PCI macros
>
> 2015-09-10 20:33, Ferruh Yigit:
> > > On Thu, Sep 10, 2015 at 6:01 PM, Ferruh Yigit
> > > <ferruh.yigit@intel.com>
> > > wrote:
> > >
> > Correct, those macros available after kernel version >= 2.6.34.
> > ...
>
> Why should we support kernel older than 2.6.34?
> Do we need to update doc/guides/rel_notes/supported_os.rst?
If we do then we should update he Linux Getting Started guide which says:
Required:
Kernel version >= 2.6.33
http://dpdk.org/doc/guides/linux_gsg/sys_reqs.html#system-software
And probably drop the section below itabout patching older kernels.
John.
--
2015-09-11 08:31, Mcnamara, John:
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon
> > 2015-09-10 20:33, Ferruh Yigit:
> > > Correct, those macros available after kernel version >= 2.6.34.
> > > ...
> >
> > Why should we support kernel older than 2.6.34?
> > Do we need to update doc/guides/rel_notes/supported_os.rst?
>
> If we do then we should update he Linux Getting Started guide which says:
>
> Required:
>
> Kernel version >= 2.6.33
>
> http://dpdk.org/doc/guides/linux_gsg/sys_reqs.html#system-software
>
> And probably drop the section below itabout patching older kernels.
Anyone against dropping 2.6.33 support?
2015-09-10 17:01, Ferruh Yigit:
> To get pci_dev and vf number from dev, benefit from
> existing macros in pci.h
>
> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
Applied, thanks
2015-10-25 18:51, Thomas Monjalon:
> 2015-09-11 08:31, Mcnamara, John:
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon
> > > 2015-09-10 20:33, Ferruh Yigit:
> > > > Correct, those macros available after kernel version >= 2.6.34.
> > > > ...
> > >
> > > Why should we support kernel older than 2.6.34?
> > > Do we need to update doc/guides/rel_notes/supported_os.rst?
> >
> > If we do then we should update he Linux Getting Started guide which says:
> >
> > Required:
> >
> > Kernel version >= 2.6.33
> >
> > http://dpdk.org/doc/guides/linux_gsg/sys_reqs.html#system-software
> >
> > And probably drop the section below itabout patching older kernels.
>
> Anyone against dropping 2.6.33 support?
This patch is now applied and is the first breaking the Linux 2.6.33 support.
John, are you OK to update the doc?
Thanks
@@ -66,8 +66,7 @@ static ssize_t
show_max_vfs(struct device *dev, struct device_attribute *attr,
char *buf)
{
- return snprintf(buf, 10, "%u\n",
- pci_num_vf(container_of(dev, struct pci_dev, dev)));
+ return snprintf(buf, 10, "%u\n", dev_num_vf(dev));
}
static ssize_t
@@ -76,7 +75,7 @@ store_max_vfs(struct device *dev, struct device_attribute *attr,
{
int err = 0;
unsigned long max_vfs;
- struct pci_dev *pdev = container_of(dev, struct pci_dev, dev);
+ struct pci_dev *pdev = to_pci_dev(dev);
if (0 != kstrtoul(buf, 0, &max_vfs))
return -EINVAL;
@@ -95,7 +94,7 @@ store_max_vfs(struct device *dev, struct device_attribute *attr,
static ssize_t
show_extended_tag(struct device *dev, struct device_attribute *attr, char *buf)
{
- struct pci_dev *pci_dev = container_of(dev, struct pci_dev, dev);
+ struct pci_dev *pci_dev = to_pci_dev(dev);
uint32_t val = 0;
pci_read_config_dword(pci_dev, PCI_DEV_CAP_REG, &val);
@@ -116,7 +115,7 @@ store_extended_tag(struct device *dev,
const char *buf,
size_t count)
{
- struct pci_dev *pci_dev = container_of(dev, struct pci_dev, dev);
+ struct pci_dev *pci_dev = to_pci_dev(dev);
uint32_t val = 0, enable;
if (strncmp(buf, "on", 2) == 0)
@@ -153,7 +152,7 @@ show_max_read_request_size(struct device *dev,
struct device_attribute *attr,
char *buf)
{
- struct pci_dev *pci_dev = container_of(dev, struct pci_dev, dev);
+ struct pci_dev *pci_dev = to_pci_dev(dev);
int val = pcie_get_readrq(pci_dev);
return snprintf(buf, PCI_SYS_FILE_BUF_SIZE, "%d\n", val);
@@ -165,7 +164,7 @@ store_max_read_request_size(struct device *dev,
const char *buf,
size_t count)
{
- struct pci_dev *pci_dev = container_of(dev, struct pci_dev, dev);
+ struct pci_dev *pci_dev = to_pci_dev(dev);
unsigned long size = 0;
int ret;