On Thu, Oct 2, 2025 at 6:36 PM Eugenio Pérez <[email protected]> wrote: > > Even if the device supports more than one class, there are ways to solve > the ambiguity of which device are we creating. In the VDUSE case it is > the name, for example.
This may only work for VDUSE but not other parents. > > RFC: I fon't understand 100% the motivation of this limitation, as the > backend should be the one filtering out the invalid features if any. I think we can avoid these tricks. Currently, there's a one single mgmt device, this seems to be in-convenient. Could we have a per device mgmt device? For example, if user space creates vduse0, vdpa mgmtdev show may see vduse0 so we won't have this issue. > > Signed-off-by: Eugenio Pérez <[email protected]> > --- > drivers/vdpa/vdpa.c | 9 --------- > 1 file changed, 9 deletions(-) > > diff --git a/drivers/vdpa/vdpa.c b/drivers/vdpa/vdpa.c > index 34874beb0152..0fc32f3bd66f 100644 > --- a/drivers/vdpa/vdpa.c > +++ b/drivers/vdpa/vdpa.c > @@ -688,15 +688,6 @@ static int vdpa_nl_cmd_dev_add_set_doit(struct sk_buff > *skb, struct genl_info *i > err = -EINVAL; > goto err; > } > - if (!(config.mask & VDPA_DEV_NET_ATTRS_MASK) && > - config.mask & BIT_ULL(VDPA_ATTR_DEV_FEATURES) && > - classes & BIT_ULL(VIRTIO_ID_NET) && ncls > 1 && > - config.device_features & VIRTIO_DEVICE_F_MASK) { > - NL_SET_ERR_MSG_MOD(info->extack, > - "Management device supports multi-class > while device features specified are ambiguous"); > - err = -EINVAL; > - goto err; > - } > > err = mdev->ops->dev_add(mdev, name, &config); > err: > -- > 2.51.0 > Thanks
