RDMA driver needs to establish admin queues to support admin operations.
Export the APIs to send device commands for the RDMA driver.
Reviewed-by: Shannon Nelson <shannon.nelson@amd.com>
Signed-off-by: Abhijit Gangurde <abhijit.gangurde@amd.com>
---
drivers/net/ethernet/pensando/ionic/ionic.h | 7 ----
.../net/ethernet/pensando/ionic/ionic_api.h | 36 +++++++++++++++++++
.../net/ethernet/pensando/ionic/ionic_dev.h | 1 +
.../net/ethernet/pensando/ionic/ionic_main.c | 4 ++-
4 files changed, 40 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/pensando/ionic/ionic.h b/drivers/net/ethernet/pensando/ionic/ionic.h
index 04f00ea94230..85198e6a806e 100644
--- a/drivers/net/ethernet/pensando/ionic/ionic.h
+++ b/drivers/net/ethernet/pensando/ionic/ionic.h
@@ -65,16 +65,9 @@ struct ionic {
int watchdog_period;
};
-struct ionic_admin_ctx {
- struct completion work;
- union ionic_adminq_cmd cmd;
- union ionic_adminq_comp comp;
-};
-
int ionic_adminq_post(struct ionic_lif *lif, struct ionic_admin_ctx *ctx);
int ionic_adminq_wait(struct ionic_lif *lif, struct ionic_admin_ctx *ctx,
const int err, const bool do_msg);
-int ionic_adminq_post_wait(struct ionic_lif *lif, struct ionic_admin_ctx *ctx);
int ionic_adminq_post_wait_nomsg(struct ionic_lif *lif, struct ionic_admin_ctx *ctx);
void ionic_adminq_netdev_err_print(struct ionic_lif *lif, u8 opcode,
u8 status, int err);
diff --git a/drivers/net/ethernet/pensando/ionic/ionic_api.h b/drivers/net/ethernet/pensando/ionic/ionic_api.h
index f9fcd1b67b35..d75902ca34af 100644
--- a/drivers/net/ethernet/pensando/ionic/ionic_api.h
+++ b/drivers/net/ethernet/pensando/ionic/ionic_api.h
@@ -5,6 +5,8 @@
#define _IONIC_API_H_
#include <linux/auxiliary_bus.h>
+#include "ionic_if.h"
+#include "ionic_regs.h"
/**
* struct ionic_aux_dev - Auxiliary device information
@@ -18,4 +20,38 @@ struct ionic_aux_dev {
struct auxiliary_device adev;
};
+/**
+ * struct ionic_admin_ctx - Admin command context
+ * @work: Work completion wait queue element
+ * @cmd: Admin command (64B) to be copied to the queue
+ * @comp: Admin completion (16B) copied from the queue
+ */
+struct ionic_admin_ctx {
+ struct completion work;
+ union ionic_adminq_cmd cmd;
+ union ionic_adminq_comp comp;
+};
+
+/**
+ * ionic_adminq_post_wait - Post an admin command and wait for response
+ * @lif: Logical interface
+ * @ctx: API admin command context
+ *
+ * Post the command to an admin queue in the ethernet driver. If this command
+ * succeeds, then the command has been posted, but that does not indicate a
+ * completion. If this command returns success, then the completion callback
+ * will eventually be called.
+ *
+ * Return: zero or negative error status
+ */
+int ionic_adminq_post_wait(struct ionic_lif *lif, struct ionic_admin_ctx *ctx);
+
+/**
+ * ionic_error_to_errno - Transform ionic_if errors to os errno
+ * @code: Ionic error number
+ *
+ * Return: Negative OS error number or zero
+ */
+int ionic_error_to_errno(enum ionic_status_code code);
+
#endif /* _IONIC_API_H_ */
diff --git a/drivers/net/ethernet/pensando/ionic/ionic_dev.h b/drivers/net/ethernet/pensando/ionic/ionic_dev.h
index c8c710cfe70c..bc26eb8f5779 100644
--- a/drivers/net/ethernet/pensando/ionic/ionic_dev.h
+++ b/drivers/net/ethernet/pensando/ionic/ionic_dev.h
@@ -12,6 +12,7 @@
#include "ionic_if.h"
#include "ionic_regs.h"
+#include "ionic_api.h"
#define IONIC_MAX_TX_DESC 8192
#define IONIC_MAX_RX_DESC 16384
diff --git a/drivers/net/ethernet/pensando/ionic/ionic_main.c b/drivers/net/ethernet/pensando/ionic/ionic_main.c
index daf1e82cb76b..60fc232338b9 100644
--- a/drivers/net/ethernet/pensando/ionic/ionic_main.c
+++ b/drivers/net/ethernet/pensando/ionic/ionic_main.c
@@ -72,7 +72,7 @@ static const char *ionic_error_to_str(enum ionic_status_code code)
}
}
-static int ionic_error_to_errno(enum ionic_status_code code)
+int ionic_error_to_errno(enum ionic_status_code code)
{
switch (code) {
case IONIC_RC_SUCCESS:
@@ -114,6 +114,7 @@ static int ionic_error_to_errno(enum ionic_status_code code)
return -EIO;
}
}
+EXPORT_SYMBOL_NS(ionic_error_to_errno, "NET_IONIC");
static const char *ionic_opcode_to_str(enum ionic_cmd_opcode opcode)
{
@@ -480,6 +481,7 @@ int ionic_adminq_post_wait(struct ionic_lif *lif, struct ionic_admin_ctx *ctx)
{
return __ionic_adminq_post_wait(lif, ctx, true);
}
+EXPORT_SYMBOL_NS(ionic_adminq_post_wait, "NET_IONIC");
int ionic_adminq_post_wait_nomsg(struct ionic_lif *lif, struct ionic_admin_ctx *ctx)
{
--
2.43.0
On Wed, Jul 23, 2025 at 11:01:38PM +0530, Abhijit Gangurde wrote: > RDMA driver needs to establish admin queues to support admin operations. > Export the APIs to send device commands for the RDMA driver. > > Reviewed-by: Shannon Nelson <shannon.nelson@amd.com> > Signed-off-by: Abhijit Gangurde <abhijit.gangurde@amd.com> Hi Abhijit, Perhaps I misunderstand things, or otherwise am on the wrong track here. But this seems to open the possibility of users of ionic_adminq_post_wait(), outside the Ethernet driver, executing a wide range or admin commands. It seems to me that it would be nice to narrow that surface. ...
On Fri, Jul 25, 2025 at 05:41:06PM +0100, Simon Horman wrote: > On Wed, Jul 23, 2025 at 11:01:38PM +0530, Abhijit Gangurde wrote: > > RDMA driver needs to establish admin queues to support admin operations. > > Export the APIs to send device commands for the RDMA driver. > > > > Reviewed-by: Shannon Nelson <shannon.nelson@amd.com> > > Signed-off-by: Abhijit Gangurde <abhijit.gangurde@amd.com> > > Hi Abhijit, > > Perhaps I misunderstand things, or otherwise am on the wrong track here. > But this seems to open the possibility of users of ionic_adminq_post_wait(), > outside the Ethernet driver, executing a wide range or admin commands. > It seems to me that it would be nice to narrow that surface. The kernel is monolithic, it is not normal to spend performance aggressively policing APIs. mlx5 and other drivers already have interfaces almost exactly like this. Jason
On Fri, 1 Aug 2025 14:00:14 -0300 Jason Gunthorpe wrote: > > Perhaps I misunderstand things, or otherwise am on the wrong track here. > > But this seems to open the possibility of users of ionic_adminq_post_wait(), > > outside the Ethernet driver, executing a wide range or admin commands. > > It seems to me that it would be nice to narrow that surface. > > The kernel is monolithic, it is not normal to spend performance > aggressively policing APIs. > > mlx5 and other drivers already have interfaces almost exactly like this. Which is not to say that it's a good idea.
On 8/2/25 01:51, Jakub Kicinski wrote: > On Fri, 1 Aug 2025 14:00:14 -0300 Jason Gunthorpe wrote: >>> Perhaps I misunderstand things, or otherwise am on the wrong track here. >>> But this seems to open the possibility of users of ionic_adminq_post_wait(), >>> outside the Ethernet driver, executing a wide range or admin commands. >>> It seems to me that it would be nice to narrow that surface. >> The kernel is monolithic, it is not normal to spend performance >> aggressively policing APIs. >> >> mlx5 and other drivers already have interfaces almost exactly like this. > Which is not to say that it's a good idea. Thank you for the feedback, and apologies for the delay. This discussion prompted a thorough internal review. Although a precedent for similar interfaces exists in other RDMA drivers, the point is well-taken and we understand the concern about a wide API. To address this, two potential approaches are being considered, 1. The function can be documented as a privileged, clarifying that it performs no input sanitization and making the caller responsible for device access. 2. Alternatively, a new, narrower function could be introduced specifically for RDMA use that validates commands against an explicit allow list. We are open to either approach and would appreciate a guidance on the preferred direction. Abhijit
On Wed, Aug 06, 2025 at 01:24:04PM +0530, Abhijit Gangurde wrote: > > On 8/2/25 01:51, Jakub Kicinski wrote: > > On Fri, 1 Aug 2025 14:00:14 -0300 Jason Gunthorpe wrote: > > > > Perhaps I misunderstand things, or otherwise am on the wrong track here. > > > > But this seems to open the possibility of users of ionic_adminq_post_wait(), > > > > outside the Ethernet driver, executing a wide range or admin commands. > > > > It seems to me that it would be nice to narrow that surface. > > > The kernel is monolithic, it is not normal to spend performance > > > aggressively policing APIs. > > > > > > mlx5 and other drivers already have interfaces almost exactly like this. > > Which is not to say that it's a good idea. > > Thank you for the feedback, and apologies for the delay. This discussion > prompted a thorough internal review. > Although a precedent for similar interfaces exists in other RDMA drivers, > the point is well-taken and we understand the concern about a wide API. To > address this, two potential approaches are being considered, > 1. The function can be documented as a privileged, clarifying that it > performs no input sanitization and making the caller responsible for device > access. > 2. Alternatively, a new, narrower function could be introduced specifically > for RDMA use that validates commands against an explicit allow list. > > We are open to either approach and would appreciate a guidance on the > preferred direction. I suggest you to take standard kernel coding pattern and create in-kernel API which suits your "in-kernel customers". There is no need in any "allow list" for in-kernel APIs. Let's don't bring complexity and defense programming style where it is not needed and here it is not needed. Thanks > > Abhijit > >
© 2016 - 2025 Red Hat, Inc.