> -----Original Message-----
> From: Jiri Pirko <jiri@xxxxxxxxxxx>
[..]
> >It should be. It isn't yet.
> >It is similar to how phys_port_name preparation was done in legacy way
> >in individual drivers and later on moved to devlink.c So some other time, can
> move this to mdev core.
>
> Btw, Documentation/driver-api/vfio-mediated-device.rst says:
> "[<type-id>], device_api, and available_instances are mandatory attributes
> that should be provided by vendor driver."
>
> Why don't you implement "device_api" as well?
Because currently device_api definitions are not central to mdev_core. It should be in mdev core and not in include/uapi/linux/vfio.h.
So, it needs to refactored.
Additionally, current mlx5 mdev are not going to be bound to vfio framework.
So, it is not breaking anything.
+ class_id is getting implemented to have more appropriate binding method.
Hence it is not implemented.
>
>
> >
> >
> >>
> >> >
> >> >>
> >> >> >+
> >> >> >+static struct attribute *mdev_dev_attrs[] = {
> >> >> >+ &mdev_type_attr_max_mdevs.attr,
> >> >> >+ &mdev_type_attr_available_instances.attr,
> >> >> >+ NULL,
> >> >> >+};
> >> >> >+
> >> >> >+static struct attribute_group mdev_mgmt_group = {
> >> >> >+ .name = "local",
>
> This local name is "type-id"?
Yes.
> Why "local?
Local to this system.
>
>
>
>
>
> >> >> >+ .attrs = mdev_dev_attrs,
> >> >> >+};
> >> >> >+
> >> >> >+static struct attribute_group *mlx5_meddev_groups[] = {
> >> >> >+ &mdev_mgmt_group,
> >> >> >+ NULL,
> >> >> >+};
> >> >>
> >> >> [...]
