Re: [RFC PATCH v2 0/9] fpga: dfl: fix kernel warning on port release/assign for SRIOV

[Xu Yilun <yilun.xu@linux.intel.com>]

On Tue, Apr 09, 2024 at 07:39:33PM -0400, Peter Colberg wrote:
> DFL ports are registered as platform devices in PF mode. The port device
> should be removed from the host when the user wants to configure the
> port as a VF and pass through to a virtual machine. The FME device
> ioctls DFL_FPGA_FME_PORT_RELEASE/ASSIGN are designed for this purpose.
> 
> In the previous implementation, the port platform device is not completely
> destroyed on port release: it is removed from the system by
> platform_device_del(), but the platform device instance is retained.
> When the port assign ioctl is called, the platform device is added back by
> platform_device_add(), which conflicts with this comment of device_add():
> "Do not call this routine more than once for any device structure", and
> will cause a kernel warning at runtime.
> 
> This patch tries to completely unregister the port platform device on
> release and registers a new one on assign. But the main work is to remove
> the dependency on struct dfl_feature_platform_data for many internal DFL
> APIs. This structure holds many DFL enumeration infos for feature devices.
> Many DFL APIs are expected to work with these info even when the port
> platform device is unregistered. But with the change the platform_data will
> be freed in this case. So this patch introduces a new structure
> dfl_feature_dev_data for these APIs, which acts similarly to the previous
> dfl_feature_platform_data. The dfl_feature_platform_data then only needs a
> pointer to dfl_feature_dev_data to make the feature device driver work.
> 
> The single monolithic v1 patch is split into multiple, smaller patches
> at the request of the maintainer. The first patch adds temporary macros
> that alias dfl_feature_dev_data ("fdata") to dfl_feature_platform_data
> ("pdata") and associated functions from the "fdata" to the corresponding
> "pdata" variants. Subsequent patches separate out most of the symbol
> name changes required by this patch series, one patch per file. The last

One patch per file is not a requirement, simple replacement across
multiple files won't cause trouble for reviewers. The important thing is
that don't bury the key changes in these symbol replacement so that
people can't get the point.