[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ZDlJES8t0nivTQLz@nvidia.com>
Date: Fri, 14 Apr 2023 09:37:37 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Shannon Nelson <shannon.nelson@....com>
Cc: Leon Romanovsky <leon@...nel.org>, brett.creeley@....com,
davem@...emloft.net, netdev@...r.kernel.org, kuba@...nel.org,
drivers@...sando.io, jiri@...nulli.us
Subject: Re: [PATCH v8 net-next 10/14] pds_core: add auxiliary_bus devices
On Sat, Apr 01, 2023 at 01:15:03PM -0700, Shannon Nelson wrote:
> We have a PF device that has an adminq, VF devices that don't have an
> adminq, and the adminq is needed for some basic setup before the rest of the
> vDPA driver can use the VF. To access the PF's adminq we set up an
> auxiliary device per feature in each VF - but currently only offer one
> feature (vDPA) and no sub-devices yet. We're trying to plan for the future.
It is the same remark I gave for the VFIO integration, the bound VF
driver should use pci_iov_get_pf_drvdata() to reach to its PF driver
and operate the admin queue. Make sure to read the comment of the
function to lock it properly.
There should not be a parallel aux device for the VF device, the
purpose of the aux device is not to allow you to find things like
admin queue objects, it is to represent a slice of device
functionality that doesn't already have a struct device
representation.
Drivers should not attempt to 'dual bind' aux device and pci device as
the original vfio patches tried to do.
Jason
Powered by blists - more mailing lists