From: Arnd Bergmann <arnd@kernel.org>
To: Leon Romanovsky <leon@kernel.org>, Jason Gunthorpe <jgg@ziepe.ca>,
Patrisious Haddad <phaddad@nvidia.com>
Cc: Arnd Bergmann <arnd@arndb.de>, Mark Bloch <mbloch@nvidia.com>,
Tariq Toukan <tariqt@nvidia.com>,
Jakub Kicinski <kuba@kernel.org>,
Moshe Shemesh <moshe@nvidia.com>,
linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH] RDMA/mlx5: hide unused code
Date: Fri, 28 Mar 2025 14:10:17 +0100 [thread overview]
Message-ID: <20250328131022.452068-1-arnd@kernel.org> (raw)
From: Arnd Bergmann <arnd@arndb.de>
After a recent rework, a few 'static const' objects have become unused:
In file included from drivers/infiniband/hw/mlx5/fs.c:27:
drivers/infiniband/hw/mlx5/fs.c:26:28: error: 'mlx5_ib_object_MLX5_IB_OBJECT_STEERING_ANCHOR' defined but not used [-Werror=unused-const-variable=]
include/rdma/uverbs_named_ioctl.h:52:47: note: in expansion of macro 'UVERBS_OBJECT'
52 | static const struct uverbs_object_def UVERBS_OBJECT(_object_id) = { \
| ^~~~~~~~~~~~~
drivers/infiniband/hw/mlx5/fs.c:3457:1: note: in expansion of macro 'DECLARE_UVERBS_NAMED_OBJECT'
3457 | DECLARE_UVERBS_NAMED_OBJECT(
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/infiniband/hw/mlx5/fs.c:26:28: error: 'mlx5_ib_object_MLX5_IB_OBJECT_FLOW_MATCHER' defined but not used [-Werror=unused-const-variable=]
include/rdma/uverbs_named_ioctl.h:52:47: note: in expansion of macro 'UVERBS_OBJECT'
52 | static const struct uverbs_object_def UVERBS_OBJECT(_object_id) = { \
| ^~~~~~~~~~~~~
drivers/infiniband/hw/mlx5/fs.c:3429:1: note: in expansion of macro 'DECLARE_UVERBS_NAMED_OBJECT'
3429 | DECLARE_UVERBS_NAMED_OBJECT(MLX5_IB_OBJECT_FLOW_MATCHER,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
These come from a complex set of macros, and it would be possible to
shut up the warnings here by adding __maybe_unused annotations inside
of the macros, it seems cleaner in this case to have a large #ifdef block
around all the unused parts of the file, in order to still be able to
catch unused ones elsewhere.
It is a bit suspicious that the various "create" functions are unused
but the corresponding "destroy" functions are still called, so it's
likely that a different approach of changing the cleanup logic as well
is actually more correct.
Fixes: 36e0d433672f ("RDMA/mlx5: Compile fs.c regardless of INFINIBAND_USER_ACCESS config")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/infiniband/hw/mlx5/fs.c | 22 +++++++++++++++++++++-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/mlx5/fs.c b/drivers/infiniband/hw/mlx5/fs.c
index 251246c73b33..f089abbed6af 100644
--- a/drivers/infiniband/hw/mlx5/fs.c
+++ b/drivers/infiniband/hw/mlx5/fs.c
@@ -684,12 +684,14 @@ enum flow_table_type {
#define MLX5_FS_MAX_TYPES 6
#define MLX5_FS_MAX_ENTRIES BIT(16)
-static bool __maybe_unused mlx5_ib_shared_ft_allowed(struct ib_device *device)
+#if IS_ENABLED(CONFIG_INFINIBAND_USER_ACCESS)
+static bool mlx5_ib_shared_ft_allowed(struct ib_device *device)
{
struct mlx5_ib_dev *dev = to_mdev(device);
return MLX5_CAP_GEN(dev->mdev, shared_object_to_user_object_allowed);
}
+#endif
static struct mlx5_ib_flow_prio *_get_prio(struct mlx5_ib_dev *dev,
struct mlx5_flow_namespace *ns,
@@ -1888,6 +1890,7 @@ static struct ib_flow *mlx5_ib_create_flow(struct ib_qp *qp,
return ERR_PTR(err);
}
+#if IS_ENABLED(CONFIG_INFINIBAND_USER_ACCESS)
static int mlx5_ib_fill_transport_ns_info(struct mlx5_ib_dev *dev,
enum mlx5_flow_namespace_type type,
u32 *flags, u16 *vport_idx,
@@ -2227,6 +2230,7 @@ static struct mlx5_ib_flow_handler *raw_fs_rule_add(
return ERR_PTR(err);
}
+#endif
static void destroy_flow_action_raw(struct mlx5_ib_flow_action *maction)
{
@@ -2263,6 +2267,7 @@ static int mlx5_ib_destroy_flow_action(struct ib_flow_action *action)
return 0;
}
+#if IS_ENABLED(CONFIG_INFINIBAND_USER_ACCESS)
static int
mlx5_ib_ft_type_to_namespace(enum mlx5_ib_uapi_flow_table_type table_type,
enum mlx5_flow_namespace_type *namespace)
@@ -2618,6 +2623,7 @@ static int steering_anchor_create_ft(struct mlx5_ib_dev *dev,
return 0;
}
+#endif
static void steering_anchor_destroy_ft(struct mlx5_ib_flow_prio *ft_prio)
{
@@ -2627,6 +2633,7 @@ static void steering_anchor_destroy_ft(struct mlx5_ib_flow_prio *ft_prio)
}
}
+#if IS_ENABLED(CONFIG_INFINIBAND_USER_ACCESS)
static int
steering_anchor_create_fg_drop(struct mlx5_ib_flow_prio *ft_prio)
{
@@ -2658,6 +2665,7 @@ steering_anchor_create_fg_drop(struct mlx5_ib_flow_prio *ft_prio)
return err;
}
+#endif
static void
steering_anchor_destroy_fg_drop(struct mlx5_ib_flow_prio *ft_prio)
@@ -2668,6 +2676,7 @@ steering_anchor_destroy_fg_drop(struct mlx5_ib_flow_prio *ft_prio)
}
}
+#if IS_ENABLED(CONFIG_INFINIBAND_USER_ACCESS)
static int
steering_anchor_create_fg_goto_table(struct mlx5_ib_flow_prio *ft_prio)
{
@@ -2695,6 +2704,7 @@ steering_anchor_create_fg_goto_table(struct mlx5_ib_flow_prio *ft_prio)
return err;
}
+#endif
static void
steering_anchor_destroy_fg_goto_table(struct mlx5_ib_flow_prio *ft_prio)
@@ -2705,6 +2715,7 @@ steering_anchor_destroy_fg_goto_table(struct mlx5_ib_flow_prio *ft_prio)
}
}
+#if IS_ENABLED(CONFIG_INFINIBAND_USER_ACCESS)
static int
steering_anchor_create_rule_drop(struct mlx5_ib_flow_prio *ft_prio)
{
@@ -2726,6 +2737,7 @@ steering_anchor_create_rule_drop(struct mlx5_ib_flow_prio *ft_prio)
return 0;
}
+#endif
static void steering_anchor_destroy_rule_drop(struct mlx5_ib_flow_prio *ft_prio)
{
@@ -2735,6 +2747,7 @@ static void steering_anchor_destroy_rule_drop(struct mlx5_ib_flow_prio *ft_prio)
}
}
+#if IS_ENABLED(CONFIG_INFINIBAND_USER_ACCESS)
static int
steering_anchor_create_rule_goto_table(struct mlx5_ib_flow_prio *ft_prio)
{
@@ -2761,6 +2774,7 @@ steering_anchor_create_rule_goto_table(struct mlx5_ib_flow_prio *ft_prio)
return 0;
}
+#endif
static void
steering_anchor_destroy_rule_goto_table(struct mlx5_ib_flow_prio *ft_prio)
@@ -2771,6 +2785,7 @@ steering_anchor_destroy_rule_goto_table(struct mlx5_ib_flow_prio *ft_prio)
}
}
+#if IS_ENABLED(CONFIG_INFINIBAND_USER_ACCESS)
static int steering_anchor_create_res(struct mlx5_ib_dev *dev,
struct mlx5_ib_flow_prio *ft_prio,
enum mlx5_flow_namespace_type ns_type)
@@ -2810,6 +2825,7 @@ static int steering_anchor_create_res(struct mlx5_ib_dev *dev,
return err;
}
+#endif
static void mlx5_steering_anchor_destroy_res(struct mlx5_ib_flow_prio *ft_prio)
{
@@ -2820,6 +2836,7 @@ static void mlx5_steering_anchor_destroy_res(struct mlx5_ib_flow_prio *ft_prio)
steering_anchor_destroy_ft(ft_prio);
}
+#ifdef CONFIG_INFINIBAND_USER_ACCESS
static int steering_anchor_cleanup(struct ib_uobject *uobject,
enum rdma_remove_reason why,
struct uverbs_attr_bundle *attrs)
@@ -2839,6 +2856,7 @@ static int steering_anchor_cleanup(struct ib_uobject *uobject,
kfree(obj);
return 0;
}
+#endif
static void fs_cleanup_anchor(struct mlx5_ib_flow_prio *prio,
int count)
@@ -2858,6 +2876,7 @@ void mlx5_ib_fs_cleanup_anchor(struct mlx5_ib_dev *dev)
fs_cleanup_anchor(dev->flow_db->rdma_tx, MLX5_IB_NUM_FLOW_FT);
}
+#if IS_ENABLED(CONFIG_INFINIBAND_USER_ACCESS)
static int mlx5_ib_matcher_ns(struct uverbs_attr_bundle *attrs,
struct mlx5_ib_flow_matcher *obj)
{
@@ -3459,6 +3478,7 @@ DECLARE_UVERBS_NAMED_OBJECT(
UVERBS_TYPE_ALLOC_IDR(steering_anchor_cleanup),
&UVERBS_METHOD(MLX5_IB_METHOD_STEERING_ANCHOR_CREATE),
&UVERBS_METHOD(MLX5_IB_METHOD_STEERING_ANCHOR_DESTROY));
+#endif
const struct uapi_definition mlx5_ib_flow_defs[] = {
#if IS_ENABLED(CONFIG_INFINIBAND_USER_ACCESS)
--
2.39.5
next reply other threads:[~2025-03-28 13:10 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-28 13:10 Arnd Bergmann [this message]
2025-03-28 13:15 ` [PATCH] RDMA/mlx5: hide unused code Jason Gunthorpe
2025-03-28 13:20 ` Arnd Bergmann
2025-03-31 9:30 ` Mark Bloch
2025-04-01 15:20 ` Patrisious Haddad
2025-04-01 15:36 ` Jason Gunthorpe
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=20250328131022.452068-1-arnd@kernel.org \
--to=arnd@kernel.org \
--cc=arnd@arndb.de \
--cc=jgg@ziepe.ca \
--cc=kuba@kernel.org \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=mbloch@nvidia.com \
--cc=moshe@nvidia.com \
--cc=phaddad@nvidia.com \
--cc=tariqt@nvidia.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