linux.git/drivers/fwctl, branch v6.18.21 Clone of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git pds_fwctl: Replace kzalloc + copy_from_user with memdup_user in pdsfc_fw_rpc 2025-09-22T13:33:10+00:00 Thorsten Blum thorsten.blum@linux.dev 2025-09-17T15:09:41+00:00 479bec4cb39a1bfb2e5d3e3959d660f61399cad4 Replace kzalloc() followed by copy_from_user() with memdup_user() to improve and simplify pdsfc_fw_rpc(). Return early if an error occurs and remove the obsolete 'err_out' label. No functional changes intended. Link: https://patch.msgid.link/r/20250917150941.168887-1-thorsten.blum@linux.dev Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Tested-by: Brett Creeley <brett.creeley@amd.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> 
Replace kzalloc() followed by copy_from_user() with memdup_user() to
improve and simplify pdsfc_fw_rpc().

Return early if an error occurs and remove the obsolete 'err_out' label.

No functional changes intended.

Link: https://patch.msgid.link/r/20250917150941.168887-1-thorsten.blum@linux.dev
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Tested-by: Brett Creeley <brett.creeley@amd.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
fwctl/mlx5: Add Adjacent function query commands and their scope 2025-09-17T13:02:09+00:00 Saeed Mahameed saeedm@nvidia.com 2025-09-08T16:52:56+00:00 e7085be863839e3438fb67da65a74b64e99917e7 MLX5_CMD_OP_QUERY_ADJACENT_FUNCTIONS_ID: - Query Adjacent functions (PFs/VFs) of the function calling FW. MLX5_CMD_OP_DELEGATE_VHCA_MANAGEMENT: - Delegates own VFs to be managed/seen by other adjacent PFs MLX5_CMD_OP_QUERY_DELEGATED_VHCA: - Query current function delegation state. Link: https://patch.msgid.link/r/20250908165256.1255985-3-saeed@kernel.org Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> 
MLX5_CMD_OP_QUERY_ADJACENT_FUNCTIONS_ID:
 - Query Adjacent functions (PFs/VFs) of the function calling FW.

MLX5_CMD_OP_DELEGATE_VHCA_MANAGEMENT:
 - Delegates own VFs to be managed/seen by other adjacent PFs

MLX5_CMD_OP_QUERY_DELEGATED_VHCA:
 - Query current function delegation state.

Link: https://patch.msgid.link/r/20250908165256.1255985-3-saeed@kernel.org
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
fwctl/mlx5: Allow MODIFY_CONG_STATUS command 2025-09-17T13:02:09+00:00 Avihai Horon avihaih@nvidia.com 2025-09-08T16:52:55+00:00 cb81f72f86e0ad7da83236c2f8b2db5a8f1310ba MODIFY_CONG_STATUS command is used to enable or disable congestion control according to a given priority and protocol. Add MODIFY_CONG_STATUS to the allowed commands under configuration scope. Link: https://patch.msgid.link/r/20250908165256.1255985-2-saeed@kernel.org Signed-off-by: Avihai Horon <avihaih@nvidia.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> 
MODIFY_CONG_STATUS command is used to enable or disable congestion control
according to a given priority and protocol.

Add MODIFY_CONG_STATUS to the allowed commands under configuration scope.

Link: https://patch.msgid.link/r/20250908165256.1255985-2-saeed@kernel.org
Signed-off-by: Avihai Horon <avihaih@nvidia.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
pds_fwctl: Remove the use of dev_err_probe() 2025-08-22T13:14:18+00:00 Liao Yuanhong liaoyuanhong@vivo.com 2025-08-20T12:40:11+00:00 f12343013022a92fff0cf22cb7b22b9c909cdbf5 Logging messages that show some type of "out of memory" error are generally unnecessary as there is a generic message and a stack dump done by the memory subsystem. These messages generally increase kernel size without much added value[1]. The dev_err_probe() doesn't do anything when error is '-ENOMEM'. Therefore, remove the useless call to dev_err_probe(), and just return the value instead. [1]: https://lore.kernel.org/lkml/1402419340.30479.18.camel@joe-AO725/ Link: https://patch.msgid.link/r/20250820124011.474224-1-liaoyuanhong@vivo.com Signed-off-by: Liao Yuanhong <liaoyuanhong@vivo.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Reviewed-by: Brett Creeley <brett.creeley@amd.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> 
Logging messages that show some type of "out of memory" error are generally
unnecessary as there is a generic message and a stack dump done by the
memory subsystem. These messages generally increase kernel size without
much added value[1].

The dev_err_probe() doesn't do anything when error is '-ENOMEM'. Therefore,
remove the useless call to dev_err_probe(), and just return the value
instead.

[1]: https://lore.kernel.org/lkml/1402419340.30479.18.camel@joe-AO725/

Link: https://patch.msgid.link/r/20250820124011.474224-1-liaoyuanhong@vivo.com
Signed-off-by: Liao Yuanhong <liaoyuanhong@vivo.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Reviewed-by: Brett Creeley <brett.creeley@amd.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
fwctl/mlx5: Fix memory alloc/free in mlx5ctl_fw_rpc() 2025-08-18T23:52:17+00:00 Akhilesh Patil akhilesh@ee.iitb.ac.in 2025-08-16T06:19:54+00:00 7f059e47326746ceebe2a984bd6124459df3b458 Use kvfree() to free memory allocated by kvzalloc() instead of kfree(). Avoid potential memory management issue considering kvzalloc() can internally choose to use either kmalloc() or vmalloc() based on memory request and current system memory state. Hence, use more appropriate kvfree() which automatically determines correct free method to avoid potential hard to debug memory issues. Fix this issue discovered by running spatch static analysis tool using coccinelle script - scripts/coccinelle/api/kfree_mismatch.cocci Fixes: 52929c2142041 ("fwctl/mlx5: Support for communicating with mlx5 fw") Link: https://patch.msgid.link/r/aKAjCoF9cT3VEbSE@bhairav-test.ee.iitb.ac.in Signed-off-by: Akhilesh Patil <akhilesh@ee.iitb.ac.in> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Reviewed-by: Alison Schofield <alison.schofield@intel.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> 
Use kvfree() to free memory allocated by kvzalloc() instead of kfree().
Avoid potential memory management issue considering kvzalloc() can
internally choose to use either kmalloc() or vmalloc() based on memory
request and current system memory state. Hence, use more appropriate
kvfree() which automatically determines correct free method to avoid
potential hard to debug memory issues.  Fix this issue discovered by
running spatch static analysis tool using coccinelle script -
scripts/coccinelle/api/kfree_mismatch.cocci

Fixes: 52929c2142041 ("fwctl/mlx5: Support for communicating with mlx5 fw")
Link: https://patch.msgid.link/r/aKAjCoF9cT3VEbSE@bhairav-test.ee.iitb.ac.in
Signed-off-by: Akhilesh Patil <akhilesh@ee.iitb.ac.in>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Reviewed-by: Alison Schofield <alison.schofield@intel.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
fwctl: Fix repeated device word in log message 2025-04-11T23:47:45+00:00 Shannon Nelson shannon.nelson@amd.com 2025-04-08T22:33:00+00:00 c92ae5d4f53ebf9c32ace69c1f89a47e8714d18b Remove the repeated word "device" from a dev_warn() message. Link: https://patch.msgid.link/r/20250408223300.24561-1-shannon.nelson@amd.com Signed-off-by: Shannon Nelson <shannon.nelson@amd.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> 
Remove the repeated word "device" from a dev_warn() message.

Link: https://patch.msgid.link/r/20250408223300.24561-1-shannon.nelson@amd.com
Signed-off-by: Shannon Nelson <shannon.nelson@amd.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
pds_fwctl: Fix type and endian complaints 2025-04-11T23:47:45+00:00 Shannon Nelson shannon.nelson@amd.com 2025-04-02T16:56:30+00:00 fd292c1f100ccd006bebb7b4fe7308e68b3753e0 Fix a number of type and endian complaints from the sparse checker. Link: https://patch.msgid.link/r/20250402165630.24288-1-shannon.nelson@amd.com Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202504020246.Dfbhxoo9-lkp@intel.com/ Signed-off-by: Shannon Nelson <shannon.nelson@amd.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> 
Fix a number of type and endian complaints from the sparse checker.

Link: https://patch.msgid.link/r/20250402165630.24288-1-shannon.nelson@amd.com
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202504020246.Dfbhxoo9-lkp@intel.com/
Signed-off-by: Shannon Nelson <shannon.nelson@amd.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
pds_fwctl: add rpc and query support 2025-03-21T23:57:55+00:00 Brett Creeley brett.creeley@amd.com 2025-03-20T19:44:11+00:00 92c66ee829b99a860a90f62ef16df3e42f92edac The pds_fwctl driver doesn't know what RPC operations are available in the firmware, so also doesn't know what scope they might have. The userland utility supplies the firmware "endpoint" and "operation" id values and this driver queries the firmware for endpoints and their available operations. The operation descriptions include the scope information which the driver uses for scope testing. Link: https://patch.msgid.link/r/20250320194412.67983-6-shannon.nelson@amd.com Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Brett Creeley <brett.creeley@amd.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Shannon Nelson <shannon.nelson@amd.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> 
The pds_fwctl driver doesn't know what RPC operations are available
in the firmware, so also doesn't know what scope they might have.  The
userland utility supplies the firmware "endpoint" and "operation" id values
and this driver queries the firmware for endpoints and their available
operations.  The operation descriptions include the scope information
which the driver uses for scope testing.

Link: https://patch.msgid.link/r/20250320194412.67983-6-shannon.nelson@amd.com
Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Brett Creeley <brett.creeley@amd.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Shannon Nelson <shannon.nelson@amd.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
pds_fwctl: initial driver framework 2025-03-21T23:57:55+00:00 Shannon Nelson shannon.nelson@amd.com 2025-03-20T19:44:10+00:00 4d09dd11d7d0e7e7f535c0abc7de19b9da6612e9 Initial files for adding a new fwctl driver for the AMD/Pensando PDS devices. This sets up a simple auxiliary_bus driver that registers with fwctl subsystem. It expects that a pds_core device has set up the auxiliary_device pds_core.fwctl Link: https://patch.msgid.link/r/20250320194412.67983-5-shannon.nelson@amd.com Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Shannon Nelson <shannon.nelson@amd.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> 
Initial files for adding a new fwctl driver for the AMD/Pensando PDS
devices.  This sets up a simple auxiliary_bus driver that registers
with fwctl subsystem.  It expects that a pds_core device has set up
the auxiliary_device pds_core.fwctl

Link: https://patch.msgid.link/r/20250320194412.67983-5-shannon.nelson@amd.com
Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Shannon Nelson <shannon.nelson@amd.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
fwctl/mlx5: Support for communicating with mlx5 fw 2025-03-06T19:13:13+00:00 Saeed Mahameed saeedm@nvidia.com 2025-02-28T00:26:35+00:00 52929c21420412b74858ee4ce71480ff9f398019 mlx5 FW has a built in security context called UID. Each UID has a set of permissions controlled by the kernel when it is created and every command is tagged by the kernel with a particular UID. In general commands cannot reach objects outside of their UID and commands cannot exceed their UID's permissions. These restrictions are enforced by FW. This mechanism has long been used in RDMA for the devx interface where RDMA will sent commands directly to the FW and the UID limitations restrict those commands to a ib_device/verbs security domain. For instance commands that would effect other VFs, or global device resources. The model is suitable for unprivileged userspace to operate the RDMA functionality. The UID has been extended with a "tools resources" permission which allows additional commands and sub-commands that are intended to match with the scope limitations set in FWCTL. This is an alternative design to the "command intent log" where the FW does the enforcement rather than having the FW report the enforcement the kernel should do. Consistent with the fwctl definitions the "tools resources" security context is limited to the FWCTL_RPC_CONFIGURATION, FWCTL_RPC_DEBUG_READ_ONLY, FWCTL_RPC_DEBUG_WRITE, and FWCTL_RPC_DEBUG_WRITE_FULL security scopes. Like RDMA devx, each opened fwctl file descriptor will get a unique UID associated with each file descriptor. The fwctl driver is kept simple and we reject commands that can create objects as the UID mechanism relies on the kernel to track and destroy objects prior to detroying the UID. Filtering into fwctl sub scopes is done inside the driver with a switch statement. This substantially limits what is possible to primarily query functions ad a few limited set operations. mlx5 already has a robust infrastructure for delivering RPC messages to fw. Trivially connect fwctl's RPC mechanism to mlx5_cmd_do(). Enforce the User Context ID in every RPC header accepted from the FD so the FW knows the security context of the issuing ID. Link: https://patch.msgid.link/r/7-v5-642aa0c94070+4447f-fwctl_jgg@nvidia.com Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> 
mlx5 FW has a built in security context called UID. Each UID has a set of
permissions controlled by the kernel when it is created and every command
is tagged by the kernel with a particular UID. In general commands cannot
reach objects outside of their UID and commands cannot exceed their UID's
permissions. These restrictions are enforced by FW.

This mechanism has long been used in RDMA for the devx interface where
RDMA will sent commands directly to the FW and the UID limitations
restrict those commands to a ib_device/verbs security domain. For instance
commands that would effect other VFs, or global device resources. The
model is suitable for unprivileged userspace to operate the RDMA
functionality.

The UID has been extended with a "tools resources" permission which allows
additional commands and sub-commands that are intended to match with the
scope limitations set in FWCTL. This is an alternative design to the
"command intent log" where the FW does the enforcement rather than having
the FW report the enforcement the kernel should do.

Consistent with the fwctl definitions the "tools resources" security
context is limited to the FWCTL_RPC_CONFIGURATION,
FWCTL_RPC_DEBUG_READ_ONLY, FWCTL_RPC_DEBUG_WRITE, and
FWCTL_RPC_DEBUG_WRITE_FULL security scopes.

Like RDMA devx, each opened fwctl file descriptor will get a unique UID
associated with each file descriptor.

The fwctl driver is kept simple and we reject commands that can create
objects as the UID mechanism relies on the kernel to track and destroy
objects prior to detroying the UID. Filtering into fwctl sub scopes is
done inside the driver with a switch statement. This substantially limits
what is possible to primarily query functions ad a few limited set
operations.

mlx5 already has a robust infrastructure for delivering RPC messages to
fw. Trivially connect fwctl's RPC mechanism to mlx5_cmd_do(). Enforce the
User Context ID in every RPC header accepted from the FD so the FW knows
the security context of the issuing ID.

Link: https://patch.msgid.link/r/7-v5-642aa0c94070+4447f-fwctl_jgg@nvidia.com
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>