On 10/30/2025 9:31 PM, Michał Winiarski wrote:
> Upcoming changes will allow users to control VF state and obtain its
> migration data with a device-level granularity (not tile/gt).
> Change the data structures to reflect that and move the GT-level
> migration init to happen after device-level init.
>
> Signed-off-by: Michał Winiarski <[email protected]>
> Reviewed-by: Michal Wajdeczko <[email protected]>
> ---
...
> diff --git a/drivers/gpu/drm/xe/xe_sriov_pf_migration_types.h
> b/drivers/gpu/drm/xe/xe_sriov_pf_migration_types.h
> new file mode 100644
> index 0000000000000..e69de29bb2d1d
> diff --git a/drivers/gpu/drm/xe/xe_sriov_pf_types.h
> b/drivers/gpu/drm/xe/xe_sriov_pf_types.h
> index c753cd59aed2b..24d22afeececa 100644
> --- a/drivers/gpu/drm/xe/xe_sriov_pf_types.h
> +++ b/drivers/gpu/drm/xe/xe_sriov_pf_types.h
> @@ -39,6 +39,12 @@ struct xe_device_pf {
> /** @provision: device level provisioning data. */
> struct xe_sriov_pf_provision provision;
>
> + /** @migration: device level VF migration data */
> + struct {
> + /** @migration.supported: indicates whether VF migration
> feature is supported */
> + bool supported;
> + } migration;
> +
late notice: all our other sub-components (except sysfs *) to hold its private
fields define its own struct that matches component name
but here, you use anonymous struct instead and what worse,
later on you start using xe_sriov_pf_migration name to hold per-VF data,
which breaks the above naming pattern even more
can you add to xe_sriov_pf_migration_types.h:
+struct xe_sriov_pf_migration {
+ /** @supported: indicates whether VF migration feature is supported */
+ bool supported;
+};
and rename per-VF struct to something else? like:
struct xe_sriov_migration_state - Per VF device-level migration related
data
*) sysfs doesn't define/use any custom data types, just kobject
> /** @service: device level service data. */
> struct xe_sriov_pf_service service;
>
