On 11/9/2022 2:51 PM, Jason Wang wrote:
On Mon, Nov 7, 2022 at 5:42 PM Zhu Lingshan <lingshan.zhu@xxxxxxxxx> wrote:
This series implements features provisioning for ifcvf.
By applying this series, we allow userspace to create
a vDPA device with selected (management device supported)
feature bits and mask out others.
I don't see a direct relationship between the first 3 and the last.
Maybe you can state the reason why the restructure is a must for the
feature provisioning. Otherwise, we'd better split the series.
When introducing features provisioning ability to ifcvf, there is a need
to re-create vDPA devices
on a VF with different feature bits.
When remove a vDPA device, the container of struct vdpa_device (here is
ifcvf_adapter) is free-ed in
dev_del() interface, so we need to allocate ifcvf_adapter in dev_add()
than in probe(). That's
why I have re-factored the adapter/mgmt_dev code.
For re-factoring the irq related code and ifcvf_base, let them work on
struct ifcvf_hw, the
reason is that the adapter is allocated in dev_add(), if we want theses
functions to work
before dev_add(), like in probe, we need them work on ifcvf_hw than the
adapter.
Thanks
Zhu Lingshan
Thanks
Please help review
Thanks
Zhu Lingshan (4):
vDPA/ifcvf: ifcvf base layer interfaces work on struct ifcvf_hw
vDPA/ifcvf: IRQ interfaces work on ifcvf_hw
vDPA/ifcvf: allocate ifcvf_adapter in dev_add()
vDPA/ifcvf: implement features provisioning
drivers/vdpa/ifcvf/ifcvf_base.c | 32 ++-----
drivers/vdpa/ifcvf/ifcvf_base.h | 10 +-
drivers/vdpa/ifcvf/ifcvf_main.c | 156 +++++++++++++++-----------------
3 files changed, 89 insertions(+), 109 deletions(-)
--
2.31.1
