From: Peter Colberg <peter.colberg@intel.com>
To: Wu Hao <hao.wu@intel.com>, Tom Rix <trix@redhat.com>,
Moritz Fischer <mdf@kernel.org>, Xu Yilun <yilun.xu@intel.com>,
linux-fpga@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: Russ Weight <russ.weight@linux.dev>,
Marco Pagani <marpagan@redhat.com>,
Matthew Gerlach <matthew.gerlach@linux.intel.com>,
Peter Colberg <peter.colberg@intel.com>
Subject: [PATCH v3 0/9] fpga: dfl: fix kernel warning on port release/assign for SRIOV
Date: Thu, 19 Sep 2024 16:34:21 -0400 [thread overview]
Message-ID: <20240919203430.1278067-1-peter.colberg@intel.com> (raw)
With the Intel FPGA PAC D5005, DFL ports are registered as platform
devices in PF mode. The port device must be removed from the host when
the user wants to configure the port as a VF for use by a user-space
driver, e.g., for pass-through to a virtual machine. The FME device
ioctls DFL_FPGA_FME_PORT_RELEASE/ASSIGN are assigned 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 DFL_FPGA_FME_PORT_ASSIGN is called, the platform device is added
back with platform_device_add(), which conflicts with this comment of
device_add(): "Do not call this routine more than once for any device
structure", and would previously cause a kernel warning at runtime.
This patch completely unregisters the port platform device on release
and registers a new device 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 infos even when
the port platform device is unregistered. But after this change, the
platform_data will be freed on port release. Hence this patch introduces
a new structure dfl_feature_dev_data, which acts similarly to the
previous dfl_feature_platform_data. dfl_feature_platform_data then only
needs a pointer to dfl_feature_dev_data to query DFL enumeration infos.
Link: https://lore.kernel.org/all/DM6PR11MB3819F9CCD0A6126B55BCB47685FB9@DM6PR11MB3819.namprd11.prod.outlook.com/T/#t
Link: https://patchwork.kernel.org/project/linux-fpga/cover/20240409233942.828440-1-peter.colberg@intel.com/
Changes since v2:
- Restructure series to break monolithic v1 patch into logical,
self-contained patches, instead of per-file patches as in v2.
In particular, the next-to-last patch only contains non-functional
changes that are strictly limited to replacing pdata with fdata.
- Omit unneeded null pointer check from fme_open(), the same as for
afu_open(). Refactor dfl_fpga_inode_to_feature_dev_data() to directly
return the platform data and retrieve the device from the data.
- Fix missing free() of type in binfo_create_feature_dev_data().
Free allocated FIU type when devm_kmemdup() returns a NULL pointer.
- Store fdata instead of pdata as file descriptor private data in
fme_open() since pdata is only used to look up fdata.
- Remove pdata pointers that are only used to look up fdata, in
dfl_fpga_dev_feature_uinit() and dfl_feature_ioctl_set_irq().
- Omit unneeded argument pdata from dfl_feature_instance_init().
- Drop redundant 0 in zero initializer of dfl_feature_platform_data in
feature_dev_register().
- Revert defining pointer to device when the pointer is only used once
per function, in afu_dma_region_add() and afu_dma_region_add().
- Revert minor, unneeded code formatting changes to reduce noise.
Changes since v1:
- Split monolithic patch into series at request of maintainer.
- Substitute binfo->type for removed function feature_dev_id_type() in
parse_feature_irqs().
- Return ERR_PTR(-ENOMEM) on !feature->params in
binfo_create_feature_dev_data().
- Reorder cdev as first member of struct dfl_feature_platform_data
such that container_of() to obtain pdata evaluates to a no-op.
- Change afu_ioctl_*() to receive dfl_feature_dev_data instead of
dfl_feature_platform_data.
- Change fme_hdr_ioctl_*() to receive dfl_feature_dev_data instead of
dfl_feature_platform_data.
- Replace local variable pdata with fdata in afu_mmap().
- Remove unused local variable pdata in afu_dev_{init,destroy}().
- Remove unused local variable pdata in fme_dev_{init,destroy}().
- Reorder local variables in afu_dma_unpin_pages() to reverse Christmas
tree order.
- Align kernel-doc function name for __dfl_fpga_cdev_find_port_data().
- Substitute @fdata for @pdata in kernel-doc comments for
dfl_fme_create_mgr() and dfl_fme_destroy_mgr().
Peter Colberg (8):
fpga: dfl: omit unneeded argument pdata from
dfl_feature_instance_init()
fpga: dfl: omit unneeded null pointer check from {afu,fme}_open()
fpga: dfl: afu: use parent device to log errors on port enable/disable
fpga: dfl: afu: define local pointer to feature device
fpga: dfl: pass feature platform data instead of device as argument
fpga: dfl: factor out feature data creation from
build_info_commit_dev()
fpga: dfl: store FIU type in feature platform data
fpga: dfl: refactor functions to take/return feature device data
Xu Yilun (1):
fpga: dfl: fix kernel warning on port release/assign for SRIOV
drivers/fpga/dfl-afu-dma-region.c | 117 ++++----
drivers/fpga/dfl-afu-error.c | 59 ++--
drivers/fpga/dfl-afu-main.c | 278 +++++++++----------
drivers/fpga/dfl-afu-region.c | 51 ++--
drivers/fpga/dfl-afu.h | 26 +-
drivers/fpga/dfl-fme-br.c | 24 +-
drivers/fpga/dfl-fme-error.c | 98 +++----
drivers/fpga/dfl-fme-main.c | 95 +++----
drivers/fpga/dfl-fme-pr.c | 86 +++---
drivers/fpga/dfl.c | 439 ++++++++++++++----------------
drivers/fpga/dfl.h | 140 ++++++----
11 files changed, 712 insertions(+), 701 deletions(-)
--
2.46.1
next reply other threads:[~2024-09-19 20:35 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-19 20:34 Peter Colberg [this message]
2024-09-19 20:34 ` [PATCH v3 1/9] fpga: dfl: omit unneeded argument pdata from dfl_feature_instance_init() Peter Colberg
2024-09-19 20:34 ` [PATCH v3 2/9] fpga: dfl: omit unneeded null pointer check from {afu,fme}_open() Peter Colberg
2024-09-24 6:28 ` Xu Yilun
2024-10-25 22:39 ` Colberg, Peter
2024-09-24 6:41 ` Xu Yilun
2024-10-25 22:40 ` Colberg, Peter
2024-09-19 20:34 ` [PATCH v3 3/9] fpga: dfl: afu: use parent device to log errors on port enable/disable Peter Colberg
2024-09-19 20:34 ` [PATCH v3 4/9] fpga: dfl: afu: define local pointer to feature device Peter Colberg
2024-09-19 20:34 ` [PATCH v3 5/9] fpga: dfl: pass feature platform data instead of device as argument Peter Colberg
2024-09-19 20:34 ` [PATCH v3 6/9] fpga: dfl: factor out feature data creation from build_info_commit_dev() Peter Colberg
2024-09-24 7:15 ` Xu Yilun
2024-10-25 22:43 ` Colberg, Peter
2024-09-19 20:34 ` [PATCH v3 7/9] fpga: dfl: store FIU type in feature platform data Peter Colberg
2024-09-24 7:42 ` Xu Yilun
2024-10-25 22:46 ` Colberg, Peter
2024-09-19 20:34 ` [PATCH v3 8/9] fpga: dfl: refactor functions to take/return feature device data Peter Colberg
2024-09-19 20:34 ` [PATCH v3 9/9] fpga: dfl: fix kernel warning on port release/assign for SRIOV Peter Colberg
2024-09-24 9:01 ` Xu Yilun
2024-10-25 22:54 ` Colberg, Peter
2024-10-26 1:52 ` Colberg, Peter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240919203430.1278067-1-peter.colberg@intel.com \
--to=peter.colberg@intel.com \
--cc=hao.wu@intel.com \
--cc=linux-fpga@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marpagan@redhat.com \
--cc=matthew.gerlach@linux.intel.com \
--cc=mdf@kernel.org \
--cc=russ.weight@linux.dev \
--cc=trix@redhat.com \
--cc=yilun.xu@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).